Re: [bug #58912] working-directory-pathname is not a parameter.

[Taylor R Campbell]

> Date: Fri,  7 Aug 2020 13:51:45 -0400 (EDT)
> From: "Arthur A. Gleckler" <INVALID.NOREPLY@gnu.org>
> 
> Per the docs, I'm trying to switch from using
> with-working-directory-pathname to using working-directory-pathname
> with parameterize.  Unfortunately, I get this result:
> 
> [...]
> 2 error> (parameter? working-directory-pathname)
> ;Value: #f
> [...]
> 
> It seems that *working-directory-pathname* is the underlying
> parameter, but it's not bound in (user).
> 
> It looks like the reason for the distinction between the two
> bindings is that the former implements a fallback for the latter
> when the working directory hasn't explicitly been set.
> 
> Is there a reason that the working directory parameter can't be set
> using the value from the microcode primitive when the process
> starts?  That would solve the problem.

Bleh.  There's a bunch of different things here all stepping on each
other's toes.

1. Every _process_ has its own working directory stored in the kernel,
   irrespective of what is stored in Scheme userland memory.  There is
   a ucode primitive to change this (set-working-directory-pathname!,
   not to be confused with the runtime procedure of the same name) but
   only a couple things use it.

2. Scheme has _userland_ state called working-directory-pathname which
   is supposed to be a full pathname to a directory that starts out
   the same as the process's working directory.

3. Scheme also has userland state called default-pathname-defaults
   which is supposed to be an incompletely filled pathname (maybe it
   has the file name and version initialized, but not the directory,
   host, or file type) that provides default values for pathnames
   missing them.

I didn't realize that we had documented deprecation of
set-working-directory-pathname! and with-working-directory-pathname
when I set about removing unnecessary vestiges of the build
environment from the band file -- mostly, the process environment and
the working directory pathname.

So I preserved their semantics, without caching a copy of the working
directory pathname in userland memory (which would then be written out
to the band file).  I did this by making working-directory-pathname a
simple procedure that first checks whether we have a local override
for the working directory pathname (using the internal parameter
*working-directory-pathname* as it used to be called), and if not,
queries the OS to find what the kernel thinks our process's working
directory pathname is, on the fly.

Really I don't understand why we have default-pathname-defaults at all
except to copy Common Lisp's archaic pathname design verbatim, and I
don't understand why we have a _parameter_ per se for the working
directory pathname when that state is really kept in the kernel and
changed only with the (f)chdir system call.

It seems to me the way it _should_ work is that each Scheme thread
should have a file descriptor open the working directory, and all
files should be opened with openat(2) or similar relative to that file
descriptor -- I think pretty much everyone supports the *at family of
system calls these days.

What are you using the working directory for?