Adam's comment seems to be the root cause of this.
One extra dot on your point Eli: this happens in case we run the
command in a regular buffer as well, not just in the scratch buffer.
Explicitly specifying the directory we expect to be in seems cleaner,
and we shall pass along a chdir flag to call-process, in order
to switch directories.
On Sat, May 22, 2021, 4:09 PM Eli Zaretskii <
eliz@gnu.org> wrote:
> Date: Sat, 22 May 2021 11:26:16 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 48579@debbugs.gnu.org
>
> > 5. Behavior on GNU/Linux: The directory matches the value shown in (2)
> > Behavior on macOS: The default directory has changed to the user's
> > home directory
> >
> > The behavior was spotted when we noticed inconsistent behavior in
> > [[https://github.com/minad/affe][affe.el]], which was subsequently
> > reproduced using =emacs -Q=
>
> The NS port checks if it's connected to a TTY when it starts, and if
> not assumes it's being run from finder and so sets the starting
> directory to something useful ($HOME), instead of / or whatever it
> defaults to.
I think any Lisp program that assumes something about the directory of
the *scratch* buffer based on where Emacs was invoked is buggy. E.g.,
on MS-Windows one can specify a starting directory for Emacs via the
properties of the Emacs desktop icon, and Lisp programs have no way of
knowing where that is.
Lisp programs that want rely on the value of the default directory
should explicitly call 'cd' to change to that directory (passing it
via command-line arguments if necessary, as it probably is in the case
in point).
Bottom line: I don't see any Emacs bug here.