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

Previous Next

Full log

Message #11 received at 48579 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: rajkrishnan1996 <at> gmail.com, 48579 <at> debbugs.gnu.org
Subject: Re: bug#48579: 28.0.50;
 Spawning an emacs process using call-process results in inconsistent
 behavior between GNU/Linux and macOS
Date: Sat, 22 May 2021 13:39:03 +0300

> Date: Sat, 22 May 2021 11:26:16 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 48579 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.