Per-process vs per-thread current-directory once more Lassi Kortela (02 Aug 2020 19:36 UTC)
Re: Per-process vs per-thread current-directory once more Marc Nieper-Wißkirchen (03 Aug 2020 07:30 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:04 UTC)
Re: Per-process vs per-thread current-directory once more Marc Nieper-Wißkirchen (03 Aug 2020 12:12 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 12:20 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:08 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:17 UTC)
Re: Per-process vs per-thread current-directory once more Lassi Kortela (03 Aug 2020 08:25 UTC)

Re: Per-process vs per-thread current-directory once more Lassi Kortela 03 Aug 2020 08:17 UTC

The best we can do is to respect the per-thread current-directory in
Scheme implementations that have one, but allow the idiom:

(parameterize ((current-directory #f))
   (readlink "foo/bar"))

to temporarily disable the per-thread current-directory for SRFI 170
procedures and use the OS current-directory.

If there's a procedure that always deal with the OS current-directory,
it should be named `os-current-directory`. The setter should be either
`set-os-current-directory!`, or an extra argument to
`os-current-directory` to mimic the usage of parameter objects.

BTW it's not guaranteed that `os-current-directory` returns the same
value that was passed to `set-os-current-directory!` due to pathname
normalization (relative to absolute; syntactic simplification; possibly
symlink resolution). Is the exclamation point appropriate in this case?

I have an (os-current-directory-as-bytevector) getter in the "Process
state as bytevectors" pre-SRFI.

<https://github.com/johnwcowan/r7rs-work/blob/master/ProcessesCowan.md>
could also have a getter for the OS process current directory since it
can make a synthetic process object as a stand-in for the current one.