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 at 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 at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Has a pulse, but that's about all.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200613/8b4bcada/attachment.html>