Hi all,
consider the following terminal session under Windows:
```powershell
cat .\test-output.st
FileStream stdout nextPutAll: 'Hello World'; lf ; flush. Smalltalk quitPrimitive.
&"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\FreshTrunk\FreshTrunk.image .\test-output.st
```
Expected output: Hello
Actual output: The VM window opens (first error because I specified the option headless) and shows up a debugger "Error: No content to install". What this error wants to mean is that it could not find the specified file. What I have to do to fix the output is to change the call to the following:
&"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\FreshTrunk\FreshTrunk.image ..\test-output.st
IMO this is a very confusing behavior because it makes it impossible to specify a relative path from the console without thinking "around the corner". If I would run ls ..\test-output.st in the same terminal context, I would get a FileNotFoundException.
I never met a comparable situation where starting a script/application from the console manipulated the pwd even before resolving the specified arguments. Is this really desirable? Could we consider this a bug?
How is the behavior on other platforms? I cannot test this at the moment because I am getting heartbeat warnings under Linux again.
Best, Christoph
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Samstag, 6. Juni 2020 17:18:44 An: Squeak Dev Betreff: [squeak-dev] Starting an image from SqueakConsole manipulates pwd
Hi all,
consider the following terminal session under Windows:
```powershell
cat .\test-output.st
FileStream stdout nextPutAll: 'Hello World'; lf ; flush. Smalltalk quitPrimitive.
&"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\FreshTrunk\FreshTrunk.image .\test-output.st
```
Expected output: Hello
Actual output: The VM window opens (first error because I specified the option headless) and shows up a debugger "Error: No content to install". What this error wants to mean is that it could not find the specified file. What I have to do to fix the output is to change the call to the following:
&"C:\Program Files (x86)\Squeak\SqueakConsole.exe" -headless .\FreshTrunk\FreshTrunk.image ..\test-output.st
IMO this is a very confusing behavior because it makes it impossible to specify a relative path from the console without thinking "around the corner". If I would run ls ..\test-output.st in the same terminal context, I would get a FileNotFoundException.
I never met a comparable situation where starting a script/application from the console manipulated the pwd even before resolving the specified arguments. Is this really desirable? Could we consider this a bug?
How is the behavior on other platforms? I cannot test this at the moment because I am getting heartbeat warnings under Linux again.
Best, Christoph
On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
If this works, I will post a patch to Inbox tomorrow.
Regards .. Subbu
On 12/06/20 11:33 pm, K K Subbu wrote:
On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
If this works, I will post a patch to Inbox tomorrow.
It won't work :-(. FileDirectory>>startUp calls setDefaultDirectory with imagePath. When I tried to change this to '.', FileDirectory>>on: changes it to '/.' :-(.
On unix, pathnames can begin with '.', '..' or '/' with the first one being the default, if a file does not begin with any one of these prefixes. These names are late bound.
FileDirectory>>splitName:to: is also broken. It returns an empty string for '/' (instead of '/') or '/foo' ('.'). A directory name can never be empty. '/' '.' '..' have to be treated specially. If a path has no delimiter than the directory is '.'. Also, the basename of '/' is '/' not empty.
I tried fixing this method, but the image crashed (couldn't find sources file). Directory is being checked for empty string in multiple places.
Does anyone have the context around these changes? Haalp!
Regards .. Subbu
Ah, the joy of trying to do sensible things cross-platform for file names.
A point to add is that not all OS necessarily make any use of a 'current directory' - RISC OS for example does strictly speaking have a legacy idea of it but generally it was ignored for anything to do with desktop applications. I *think* early Mac OS (up to OS X probably) had the same view. After all, if you run squeak by double-clicking on an image file in a filer window, what is the meaning of CWD?
Most likely we settled on directory of the image file' as a good proxy since it was actually discoverable from information we already had on startup. It's a pain when using things like any of the all-in-ones of course.
In cases where we start a system via some form of script we might do some work and pass the desired home directory via DTLs nice new -doit option, which could allow the all-in-one scripts to set it to something more sensible than /Users/tim/Documents/Squeak/Squeak-5.0-All-in-One.app/Contents/Resources/ when /Users/tim/Documents/Squeak would seem more plausibly useful.
And as for the mess that can occur when playing with filenames ... yeah. I've tried to make it better in the past (like probably 1998 was the last time I got up enough enthusiasm to be thrown into that briar patch) but it really needs a complete rethink, rewrite and replacement. We have had, in deep history, long threads about how to tackle this, with ideas about checking for file properties (problem: they can change in the backgrouund due to other processes), file name rules (can vary file by file according to the filesystem mounted - is it FAT, FAT32, NTFS, ext4, zfs, ftp, adfs?), and on and on.
IIRC their *was* a big push for this that resulted in 'FilePath' or something remotely like that in name? Beuller? Anyone?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has a pulse, but that's about all.
Hi Tim,
In the FileSystem API you can set a current directory for each FileSystem object. But it also has "locator" objects, such as home directory, image directory, VM directory, and a few more. You can resolve relative paths or relative file/directory references against such a locator or location to get resolved references. Is that what you mean?
In addition to that, what you wrote makes sense to me: GUI applications, or rather non-shell applications (think of services/daemons) should not depend on a current working directory. But if Squeak becomes a script interpreter or command line utility with --doit and such, it suddenly is a shell application and should therefore consider the shell's working directory, /not/ the image's directory in my opinion.
Kind regards, Jakob
tim Rowledge tim@rowledge.org schrieb am Sa., 13. Juni 2020, 19:39:
Ah, the joy of trying to do sensible things cross-platform for file names.
A point to add is that not all OS necessarily make any use of a 'current directory' - RISC OS for example does strictly speaking have a legacy idea of it but generally it was ignored for anything to do with desktop applications. I *think* early Mac OS (up to OS X probably) had the same view. After all, if you run squeak by double-clicking on an image file in a filer window, what is the meaning of CWD?
Most likely we settled on directory of the image file' as a good proxy since it was actually discoverable from information we already had on startup. It's a pain when using things like any of the all-in-ones of course.
In cases where we start a system via some form of script we might do some work and pass the desired home directory via DTLs nice new -doit option, which could allow the all-in-one scripts to set it to something more sensible than /Users/tim/Documents/Squeak/Squeak-5.0-All-in-One.app/Contents/Resources/ when /Users/tim/Documents/Squeak would seem more plausibly useful.
And as for the mess that can occur when playing with filenames ... yeah. I've tried to make it better in the past (like probably 1998 was the last time I got up enough enthusiasm to be thrown into that briar patch) but it really needs a complete rethink, rewrite and replacement. We have had, in deep history, long threads about how to tackle this, with ideas about checking for file properties (problem: they can change in the backgrouund due to other processes), file name rules (can vary file by file according to the filesystem mounted - is it FAT, FAT32, NTFS, ext4, zfs, ftp, adfs?), and on and on.
IIRC their *was* a big push for this that resulted in 'FilePath' or something remotely like that in name? Beuller? Anyone?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has a pulse, but that's about all.
Isn't that intended? You have a large number of images somewhere on your disk but only a handful of VMs. From Squeak's perspective, the current working directory should be where that image is located, not the VM.
Best, Marcel Am 12.06.2020 20:03:39 schrieb K K Subbu kksubbu.ml@gmail.com: On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
If this works, I will post a patch to Inbox tomorrow.
Regards .. Subbu
On 14/06/20 1:09 pm, Marcel Taeumel wrote:
Isn't that intended? You have a large number of images somewhere on your disk but only a handful of VMs. From Squeak's perspective, the current working directory should be where that image is located, not the VM.
Marcel,
If you don't mind, I will continue this discussion in a separate thread.
The unix vm does not change CWD when started from a console, so this thread should really be closed.
Regards .. Subbu
Hi
On 12.06.2020, at 20:03, K K Subbu kksubbu.ml@gmail.com wrote:
On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
If this works, I will post a patch to Inbox tomorrow.
Regards .. Subbu
What would the cwd be if you double-click on a desktop (linux/win/mac)? most users do not start the image using a shell… -t
On 14/06/20 1:14 pm, Tobias Pape wrote:
What would the cwd be if you double-click on a desktop (linux/win/mac)? most users do not start the image using a shell…
It shouldn't matter. CWD is a property of the current process and shared between the vm and plugin. It is just one of the platform-specific paths that is used to resolve partial names into complete paths. I don't see a need for the image to resolve the complete path before calling the plugin to open/create files.
Instead of expecting the image to only give complete paths, let the plugin resolve partial paths like 'squeak.image' by looking up a list of directories like vmPath, CWD or even something like $HOME or $DOCUMENTS.
Earlier, someone (Tim?) proposed that squeak.image/changes be distributed in the VM directory as readonly and let developers save copies in their own directory. It will be trivial to support such deployments if plugins resolved partial names too.
Regards .. Subbu
On 14.06.2020, at 12:18, K K Subbu kksubbu.ml@gmail.com wrote:
On 14/06/20 1:14 pm, Tobias Pape wrote:
What would the cwd be if you double-click on a desktop (linux/win/mac)? most users do not start the image using a shell…
It shouldn't matter. CWD is a property of the current process and shared between the vm and plugin. It is just one of the platform-specific paths that is used to resolve partial names into complete paths. I don't see a need for the image to resolve the complete path before calling the plugin to open/create files.
It sure does.
Instead of expecting the image to only give complete paths, let the plugin resolve partial paths like 'squeak.image' by looking up a list of directories like vmPath, CWD or even something like $HOME or $DOCUMENTS.
kpsewhich, here we come xD
Earlier, someone (Tim?) proposed that squeak.image/changes be distributed in the VM directory as readonly and let developers save copies in their own directory. It will be trivial to support such deployments if plugins resolved partial names too.
We can handle that without changing any file or plugin logic, already. I've just not had the time to implement the copying logic.
Best regards -Tobias
On 12.06.2020, at 20:03, K K Subbu kksubbu.ml@gmail.com wrote:
On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
I think we've established that this is not necessarily the case, certainly not for all platforms.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IXM: Initiate X-rated error Messages
Hi all,
(yep, I'm cleaning up my old inbox messages today. :D)
What is the current state of this issue? IMO it is still an undesired behavior and if I understand it correctly, it should be fixed on the VM side. Will it be appropriate to open a ticket in the OSVM repo before we all forget this? ;-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Sonntag, 14. Juni 2020 17:38:45 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Starting an image from SqueakConsole manipulates pwd
On 12.06.2020, at 20:03, K K Subbu kksubbu.ml@gmail.com wrote:
On 12/06/20 7:24 pm, Thiede, Christoph wrote:
I just rechecked this under Ubuntu. Same issue here. Do you agree that it is a bug that the pwd is changed when starting the VM?
On all platforms, the default directory is the current directory, but FileDirectory>>startUp is setting the default directory to that of the image instead of current directory. The attached fix will cure the fault.
I think we've established that this is not necessarily the case, certainly not for all platforms.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IXM: Initiate X-rated error Messages
squeak-dev@lists.squeakfoundation.org
-
Jakob Reschke -
K K Subbu -
Marcel Taeumel -
Thiede, Christoph -
tim Rowledge -
Tobias Pape