bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent behavior between GNU/Linux and macOS

[Raj Krishnan <rajkrishnan1996@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

Thanks Alan, Eli!


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.
>

[-- Attachment #2: Type: text/html, Size: 2702 bytes --]