Am Do., 23. Apr. 2020 um 17:16 Uhr schrieb Sebastien Marie <xxxxxx@online.fr>:

>> [...]
>>
>> I am a bit shared. I understand that having proper "current working
>> directory" based on parameter-like semantic, and having it per
>> thread could be a good thing. But SRFI 170 is about "POSIX API", and
>> I would expect the standard behaviour found in C world, where
>> getcwd() is a per-process property (but I didn't found formal
>> definition of cwd as process property in Posix definition).
>>
>> At minima, the direct reference about getcwd() and chdir() should be
>> avoided, and the difference with them properly documented.
>>
>> The same reasoning could be done about umask (but here, Posix is
>> explicitly saying that it is a property of the process).
>
> What about thinking of SRFI 170 as the low-level bare-metal
> interface mimicking C/POSIX as much as possible? On top of that, a
> more Schemely-SRFI could be layered, in which the current working
> directory is a parameter object. I agree that the per-thread
> semantics are more sound.

A low-level bare-metal style interface has been the general philosophy
of SRFI 170, except for providing higher level functionality where
it was thought a simple wrapper would likely cause problems.

For example, the procedures that change terminal modes are designed to
avoid leaving it in a non-echoing state if at all possible, avoiding
the old hack of having to blindly type ^Jreset^J.

- Harold