> On Apr 23, 2020, at 10:13 AM, John Cowan <xxxxxx@ccil.org> wrote:
>
> Here's my proposal, after reflection;
>
> 1) SRFI 170 `working-directory` and `umask` are per-thread if and only if the other R7RS procedures that accept pathnames are implemented using per-thread versions in a particular Scheme implementation providing SRFI 170.
>
> 2) SRFI 170 does not specify whether these procedures are parameters or not.
>
> 3) R7RS does not specify (or prevent) assignment to a parameter as opposed to binding it; therefore `set-working-directory` and `set-umask` are the only portable ways to change their values, whether per-thread or per-process.
>
> 4) For the avoidance of doubt, all this will be spelled out in the SRFI text.
>
> Comments?

Just to make sure you didn’t miss this:

I understand that SRFI 170 is about the POSIX API where chdir(), and also umask(), have a well defined behaviour.

I would like however for SRFI 170 to include a statement that calls to chdir() do not affect the behaviour of open-input-file, etc.  This has to be very clear because many programmers will assume that there is a link between the process CWD and the interpretation of relative paths by open-input-file, etc.

This suggests a need to add to SRFI 170 a procedure such as (process-path->absolute string) that interprets “string” according to the process’ CWD and returns an absolute path that can be used by open-input-file, etc

Marc