parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 08:08 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 10:16 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:19 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 30 Apr 2020 15:38 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:42 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 30 Apr 2020 15:47 UTC
Re: parameterized working-directory and changing it relatively John Cowan 30 Apr 2020 15:49 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 16:00 UTC
Re: parameterized working-directory and changing it relatively Faré 30 Apr 2020 16:01 UTC
Re: parameterized working-directory and changing it relatively Lassi Kortela 30 Apr 2020 18:25 UTC
Re: parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 19:27 UTC
Re: parameterized working-directory and changing it relatively Faré 01 May 2020 01:19 UTC
Re: parameterized working-directory and changing it relatively Marc Nieper-Wißkirchen 01 May 2020 07:43 UTC
Re: parameterized working-directory and changing it relatively John Cowan 01 May 2020 13:15 UTC
Re: parameterized working-directory and changing it relatively Faré 03 May 2020 10:23 UTC
Re: parameterized working-directory and changing it relatively Shiro Kawai 30 Apr 2020 17:39 UTC

Re: parameterized working-directory and changing it relatively Faré 30 Apr 2020 16:01 UTC

Sorry for being a late-comer to this discussion, but I *staunchly*
oppose the entire "provide a thread-local current-directory API when
the system doesn't" approach:

- The standard should provide as thin layers around the operating
system as makes sense, and let users build their abstractions. Either
the abstractions can be built, in which case we should let the user
build them. Or they cannot be built, in which case the radioactive
mess of failure trying to build them should not be part of the
language.

- In particular, if the language does not allow the abstraction to be
built *as a library*, then the problem comes with the language's lack
of abstraction, not with its lack of primitives.

- If the operating system interface is completely broken (such as
inotify being unreliable or signals being lost), no amount of papering
over it can save the user, let alone provide them with a
one-size-fits-all solution with dealing with the issue.

- POSIX says that threads share current directory. RnRS should
acknowledge that, and anything else is bullshit. Don't break user
expectations with "magic" that is actually a curse.

- Using directory names is STUPID AND EVIL and chdir should NEVER,
EVER be used outside the user control. If you *HAVE* to do something,
use fchdir instead. There are ESSENTIAL CASES where the entire
"normalize to absolute path" makes NO SENSE WHATSOEVER: the process
may not have access to parent directories, hidden by a mount, by a
chroot, by a missing a unlink/unlinkat, by a missing permission or
capability, a renamed directory, a moved symlink, etc. Trying to
change directory by name is then completely broken and a huge security
vulnerability. Also, not all systems that you may run Scheme on may
have a functional fchdir.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There are two kinds of problems with a tool: either it should do a
thing and doesn't, or it shouldn't do a
thing yet does. — Michael Raskin