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

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

[Raj Krishnan]

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

Steps for reproduction:
1. Run =emacs -Q= in some directory outside the user's home directory
2. Check the value of the variable =default-directory=, and verify that
   it matches the directory you started emacs in
3. Create an emacs child process using:

#+begin_src emacs_lisp
  (call-process
    (file-truename (expand-file-name invocation-name invocation-directory))
    nil nil nil "-Q")
#+end_src

4. In the newly created frame, check the value of the default directory

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=




In GNU Emacs 28.0.50 (build 2, aarch64-apple-darwin20.4.0, NS
appkit-2022.44 Version 11.3.1 (Build 20E241))
 of 2021-05-16 built on localhost
Repository revision: 1b8f013d179e8866819fe53b4708b57e753a08fc
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1

Configured using:
 'configure --with-ns --with-modules --with-gnutls CFLAGS=-O3'

Configured features:
ACL GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG THREADS TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_IN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 50394 13010)
 (symbols 48 6513 1)
 (strings 32 18129 1897)
 (string-bytes 1 601636)
 (vectors 16 12488)
 (vector-slots 8 175753 14592)
 (floats 8 21 50)
 (intervals 56 206 0)
 (buffers 992 11))

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

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

[Alan Third]

On Sat, May 22, 2021 at 11:00:43AM +0530, Raj Krishnan wrote:
> Steps for reproduction:
> 1. Run =emacs -Q= in some directory outside the user's home directory
> 2. Check the value of the variable =default-directory=, and verify that
>    it matches the directory you started emacs in
> 3. Create an emacs child process using:
> 
> #+begin_src emacs_lisp
>   (call-process
>     (file-truename (expand-file-name invocation-name invocation-directory))
>     nil nil nil "-Q")
> #+end_src
> 
> 4. In the newly created frame, check the value of the default directory
> 
> 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.

-- 
Alan Third

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

[Eli Zaretskii]

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

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

[Raj Krishnan]

[-- 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 --]

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

[Daniel Mendler]

> Bottom line: I don't see any Emacs bug here.

Of course there is an Emacs bug here.

I am using `call-process` to start Emacs. On Mac the home directory is
taken on other Unixes the current directory of the parent process is taken.

Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
in the same way on both platforms with regards to handling the current
directory. When Emacs is started via the command line or via forking
from another process, Emacs should inherit the default directory from
the parent process. If Emacs is started via some special finder or
desktop application, the default directory of that finder application is
taken. This is all predictable and expected.

Daniel

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

[Alan Third]

On Sat, May 22, 2021 at 01:44:27PM +0200, Daniel Mendler wrote:
> Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
> in the same way on both platforms with regards to handling the current
> directory. When Emacs is started via the command line or via forking
> from another process, Emacs should inherit the default directory from
> the parent process. If Emacs is started via some special finder or
> desktop application, the default directory of that finder application is
> taken. This is all predictable and expected.

If you want Emacs on macOS to work like a Unix command line app, then
build it as a Unix command line app, not a macOS GUI app.
-- 
Alan Third

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

[Daniel Mendler]

On 5/22/21 2:06 PM, Alan Third wrote:
> On Sat, May 22, 2021 at 01:44:27PM +0200, Daniel Mendler wrote:
>> Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
>> in the same way on both platforms with regards to handling the current
>> directory. When Emacs is started via the command line or via forking
>> from another process, Emacs should inherit the default directory from
>> the parent process. If Emacs is started via some special finder or
>> desktop application, the default directory of that finder application is
>> taken. This is all predictable and expected.
> 
> If you want Emacs on macOS to work like a Unix command line app, then
> build it as a Unix command line app, not a macOS GUI app.

I am not talking about GUI vs terminal, the problem here is if Emacs is
started from a script. Would it be possible to adjust the directory
changing behavior, for example if Emacs is started with the arguments
`--daemon`, `--batch` or `--script`? Is there another way to detect if
the finder launched Emacs, such that only in that case the directory
changing to the home directory takes place?

Daniel

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

[Eli Zaretskii]

> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 14:14:53 +0200
> 
> > If you want Emacs on macOS to work like a Unix command line app, then
> > build it as a Unix command line app, not a macOS GUI app.
> 
> I am not talking about GUI vs terminal, the problem here is if Emacs is
> started from a script. Would it be possible to adjust the directory
> changing behavior, for example if Emacs is started with the arguments
> `--daemon`, `--batch` or `--script`? Is there another way to detect if
> the finder launched Emacs, such that only in that case the directory
> changing to the home directory takes place?

That won't help.  The initial directory in which Emacs starts can be
controlled that way, but that's not what you will see in some random
buffer's default-directory.  It is completely OK for Emacs to change
its cwd, as far as the OS is concerned, after it was started, because
that directory doesn't affect how Emacs works.

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

[Daniel Mendler]

On 5/22/21 2:29 PM, Eli Zaretskii wrote:
>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Sat, 22 May 2021 14:14:53 +0200
>>
>>> If you want Emacs on macOS to work like a Unix command line app, then
>>> build it as a Unix command line app, not a macOS GUI app.
>>
>> I am not talking about GUI vs terminal, the problem here is if Emacs is
>> started from a script. Would it be possible to adjust the directory
>> changing behavior, for example if Emacs is started with the arguments
>> `--daemon`, `--batch` or `--script`? Is there another way to detect if
>> the finder launched Emacs, such that only in that case the directory
>> changing to the home directory takes place?
> 
> That won't help.  The initial directory in which Emacs starts can be
> controlled that way, but that's not what you will see in some random
> buffer's default-directory.  It is completely OK for Emacs to change
> its cwd, as far as the OS is concerned, after it was started, because
> that directory doesn't affect how Emacs works.

I am not talking about a random directory of some random buffer. Of
course these buffers have default-directories depending on if a file is
visited and so on. I am talking about the default-directory of the
initial *scratch* buffer, which runs the script loaded directly after
launch. This is relevant in case you want to start worker jobs executing
some code asynchronously for example, related to the current discussion
on the mailing list (emacsclient in elisp).

Daniel

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

[Eli Zaretskii]

> Cc: alan@idiocy.org, 48579@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 14:41:22 +0200
> 
> I am not talking about a random directory of some random buffer. Of
> course these buffers have default-directories depending on if a file is
> visited and so on. I am talking about the default-directory of the
> initial *scratch* buffer, which runs the script loaded directly after
> launch. This is relevant in case you want to start worker jobs executing
> some code asynchronously for example, related to the current discussion
> on the mailing list (emacsclient in elisp).

You should use absolute file names.

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

[Alan Third]

On Sat, May 22, 2021 at 02:14:53PM +0200, Daniel Mendler wrote:
> On 5/22/21 2:06 PM, Alan Third wrote:
> > On Sat, May 22, 2021 at 01:44:27PM +0200, Daniel Mendler wrote:
> >> Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
> >> in the same way on both platforms with regards to handling the current
> >> directory. When Emacs is started via the command line or via forking
> >> from another process, Emacs should inherit the default directory from
> >> the parent process. If Emacs is started via some special finder or
> >> desktop application, the default directory of that finder application is
> >> taken. This is all predictable and expected.
> > 
> > If you want Emacs on macOS to work like a Unix command line app, then
> > build it as a Unix command line app, not a macOS GUI app.
> 
> I am not talking about GUI vs terminal,

You kind of are. The only reason this would happen is that the emacs
executable you're executing is within the GUI app bundle or at least
has been built to run as such.

> the problem here is if Emacs is started from a script. Would it be
> possible to adjust the directory changing behavior, for example if
> Emacs is started with the arguments `--daemon`, `--batch` or
> `--script`? Is there another way to detect if the finder launched
> Emacs, such that only in that case the directory changing to the
> home directory takes place?

You can run with "-t", "-nw", "--chdir", "--batch" or "--script" to
disable this behaviour.

-- 
Alan Third

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

[Daniel Mendler]

On 5/22/21 3:01 PM, Alan Third wrote:
>> the problem here is if Emacs is started from a script. Would it be
>> possible to adjust the directory changing behavior, for example if
>> Emacs is started with the arguments `--daemon`, `--batch` or
>> `--script`? Is there another way to detect if the finder launched
>> Emacs, such that only in that case the directory changing to the
>> home directory takes place?
> 
> You can run with "-t", "-nw", "--chdir", "--batch" or "--script" to
> disable this behaviour.

I am currently using "--chdir" to work around this. If "--batch" also
opts out of this behavior I am actually happy, as I wrote in an earlier
mail. I am sorry that I could not test this, since I do not have a Mac
available.

For my purposes using "--batch" is probably the correct setting and I
should have used that right away. It is kind of unclear to me what other
settings are affected by "--batch"? It sets `noninteractive` for example.

Feel free to close this bug report then!

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

[Eli Zaretskii]

> Date: Sat, 22 May 2021 14:01:06 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 48579@debbugs.gnu.org
> 
> > the problem here is if Emacs is started from a script. Would it be
> > possible to adjust the directory changing behavior, for example if
> > Emacs is started with the arguments `--daemon`, `--batch` or
> > `--script`? Is there another way to detect if the finder launched
> > Emacs, such that only in that case the directory changing to the
> > home directory takes place?
> 
> You can run with "-t", "-nw", "--chdir", "--batch" or "--script" to
> disable this behaviour.

That again doesn't necessarily mean you'd be able to tell the cwd of
the Emacs process at any time during the session.

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

[Daniel Mendler]

On 5/22/21 3:10 PM, Eli Zaretskii wrote:
>> You can run with "-t", "-nw", "--chdir", "--batch" or "--script" to
>> disable this behaviour.
> 
> That again doesn't necessarily mean you'd be able to tell the cwd of
> the Emacs process at any time during the session.

Eli, I understand the point you are making here. In general you are
right. But the current behavior is good enough for me. Feel free to
close the issue then.

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

[Lars Ingebrigtsen]

Daniel Mendler <mail@daniel-mendler.de> writes:

>> That again doesn't necessarily mean you'd be able to tell the cwd of
>> the Emacs process at any time during the session.
>
> Eli, I understand the point you are making here. In general you are
> right. But the current behavior is good enough for me. Feel free to
> close the issue then.

Skimming this bug report, it seems like the conclusion is that we don't
want to change how Emacs behaves here, and I'm therefore closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> Cc: alan@idiocy.org, 48579@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 13:44:27 +0200
> 
> Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
> in the same way on both platforms with regards to handling the current
> directory. When Emacs is started via the command line or via forking
> from another process, Emacs should inherit the default directory from
> the parent process.

If this is what you think, then your concept of the default-directory
is in direct contradiction with how Emacs works.  The cwd of the Emacs
process is immaterial, and actually not even easily visible inside
Emacs.  When a buffer visits a file, Emacs makes a point of behaving
like that file's directory was its cwd.  For other buffers, my
suggestion is to consider their default-directory to be indeterminate,
and if you need it to have a specified value, you should force that by
calling 'cd' or setting default-directory explicitly.  Anything else
is bound to trip you some day, because it simply isn't how Emacs was
designed to behave.

So when you say that Emacs should behave the same on these platforms,
you should first ask yourself what is that "same behavior".  My answer
is simple: you cannot predict what is the default-directory of a
random buffer that doesn't visit a file.  In this sense, Emacs indeed
works the same on all platforms.  Any other sense you may wish to
assign to that is simply a basic mistake.

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

[Daniel Mendler]

On 5/22/21 2:20 PM, Eli Zaretskii wrote:
>> Cc: alan@idiocy.org, 48579@debbugs.gnu.org
>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Sat, 22 May 2021 13:44:27 +0200
>>
>> Both GNU/Linux and macOS are Unixes, it is expected that Emacs behaves
>> in the same way on both platforms with regards to handling the current
>> directory. When Emacs is started via the command line or via forking
>> from another process, Emacs should inherit the default directory from
>> the parent process.
> 
> If this is what you think, then your concept of the default-directory
> is in direct contradiction with how Emacs works.  The cwd of the Emacs
> process is immaterial, and actually not even easily visible inside
> Emacs.  When a buffer visits a file, Emacs makes a point of behaving
> like that file's directory was its cwd.  For other buffers, my
> suggestion is to consider their default-directory to be indeterminate,
> and if you need it to have a specified value, you should force that by
> calling 'cd' or setting default-directory explicitly.  Anything else
> is bound to trip you some day, because it simply isn't how Emacs was
> designed to behave.

I am aware that the file visiting buffers have a different
default-directory. However the initial scratch buffer should inherit the
current working directory of the parent process. I don't see why some
"indeterminate" or "undefined" behavior is justified here.

> So when you say that Emacs should behave the same on these platforms,
> you should first ask yourself what is that "same behavior".  My answer
> is simple: you cannot predict what is the default-directory of a
> random buffer that doesn't visit a file.  In this sense, Emacs indeed
> works the same on all platforms.  Any other sense you may wish to
> assign to that is simply a basic mistake.

There is no technical roadblock preventing Emacs from determining the
current directory (at least on Unixes). The problem is that the Mac
Emacs port changes the directory according to its own standards.

Why do you call this "indeterminate", "undefined" or "random" behavior?
Are there other examples where buffers have random directories?

Daniel

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

[Eli Zaretskii]

> Cc: alan@idiocy.org, 48579@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 14:37:35 +0200
> 
> > If this is what you think, then your concept of the default-directory
> > is in direct contradiction with how Emacs works.  The cwd of the Emacs
> > process is immaterial, and actually not even easily visible inside
> > Emacs.  When a buffer visits a file, Emacs makes a point of behaving
> > like that file's directory was its cwd.  For other buffers, my
> > suggestion is to consider their default-directory to be indeterminate,
> > and if you need it to have a specified value, you should force that by
> > calling 'cd' or setting default-directory explicitly.  Anything else
> > is bound to trip you some day, because it simply isn't how Emacs was
> > designed to behave.
> 
> I am aware that the file visiting buffers have a different
> default-directory. However the initial scratch buffer should inherit the
> current working directory of the parent process.

Like I said: this last expectation is wrong in Emacs.  The cwd of the
Emacs process is carefully concealed from Lisp, by design.  My advice
is not to make the assumption you do, because Emacs doesn't promise
you it will follow it.

> I don't see why some "indeterminate" or "undefined" behavior is
> justified here.

It is justified because that's how Emacs was designed.

> There is no technical roadblock preventing Emacs from determining the
> current directory (at least on Unixes).

Right, no roadblocks.  And Emacs does determine that, for its own
purposes, on all platforms.  It just doesn't expose that to Lisp.

> The problem is that the Mac Emacs port changes the directory
> according to its own standards.

I see no problem here.  There's nothing wrong with that behavior.

> Why do you call this "indeterminate", "undefined" or "random" behavior?
> Are there other examples where buffers have random directories?

They aren't random.

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

[Daniel Mendler]

On 5/22/21 2:46 PM, Eli Zaretskii wrote:
>> I am aware that the file visiting buffers have a different
>> default-directory. However the initial scratch buffer should inherit the
>> current working directory of the parent process.
> 
> Like I said: this last expectation is wrong in Emacs.  The cwd of the
> Emacs process is carefully concealed from Lisp, by design.  My advice
> is not to make the assumption you do, because Emacs doesn't promise
> you it will follow it.
>
>> There is no technical roadblock preventing Emacs from determining the
>> current directory (at least on Unixes).
> 
> Right, no roadblocks.  And Emacs does determine that, for its own
> purposes, on all platforms.  It just doesn't expose that to Lisp.

This statement does not seem correct to me. There is a default-directory
which I can access in the initial *scratch* buffer. Something is exposed
here. Why is the default-directory not nil then?

Seriously, what is the justification for this? If Emacs determines the
current working directory on all platforms, why does it not guarantee
that the initial *scratch* buffer sees this directory?

But this discussion here seems to be a bit off-track. My point here is
that the current working directory determination on MacOS uses a
heuristic, which is not correct. It incorrectly determines that Emacs
has been launched from the finder or some other Mac GUI application and
therefore changes the directory to the home directory. If Emacs is
indeed started from the GUI, this makes all sense. But this is not the
case here. The TTY heuristic, that Alan described, is insufficient.

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

[Alan Third]

On Sat, May 22, 2021 at 02:54:26PM +0200, Daniel Mendler wrote:
> But this discussion here seems to be a bit off-track. My point here is
> that the current working directory determination on MacOS uses a
> heuristic, which is not correct. It incorrectly determines that Emacs
> has been launched from the finder or some other Mac GUI application and
> therefore changes the directory to the home directory. If Emacs is
> indeed started from the GUI, this makes all sense. But this is not the
> case here. The TTY heuristic, that Alan described, is insufficient.

I can't find any other way, and we had multiple complaints when the
behaviour was broken whereas this is the first complaint in the other
direction that I've seen.

If you find an alternative, please let us know.
-- 
Alan Third

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

[Daniel Mendler]

On 5/22/21 3:04 PM, Alan Third wrote:
> On Sat, May 22, 2021 at 02:54:26PM +0200, Daniel Mendler wrote:
>> But this discussion here seems to be a bit off-track. My point here is
>> that the current working directory determination on MacOS uses a
>> heuristic, which is not correct. It incorrectly determines that Emacs
>> has been launched from the finder or some other Mac GUI application and
>> therefore changes the directory to the home directory. If Emacs is
>> indeed started from the GUI, this makes all sense. But this is not the
>> case here. The TTY heuristic, that Alan described, is insufficient.
> 
> I can't find any other way, and we had multiple complaints when the
> behaviour was broken whereas this is the first complaint in the other
> direction that I've seen.
> 
> If you find an alternative, please let us know.

As I wrote, if "--batch" opts out of this, I am happy. I should have
used "--batch" right away in my program. Since this is what I am doing -
I am starting a batch background worker job. I just wasn't aware of the
opt-out. Hopefully the batch setting does not have other unexpected side
effects.

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

[Daniel Mendler]

On 5/22/21 3:13 PM, Daniel Mendler wrote:
> On 5/22/21 3:04 PM, Alan Third wrote:
>> On Sat, May 22, 2021 at 02:54:26PM +0200, Daniel Mendler wrote:
>>> But this discussion here seems to be a bit off-track. My point here is
>>> that the current working directory determination on MacOS uses a
>>> heuristic, which is not correct. It incorrectly determines that Emacs
>>> has been launched from the finder or some other Mac GUI application and
>>> therefore changes the directory to the home directory. If Emacs is
>>> indeed started from the GUI, this makes all sense. But this is not the
>>> case here. The TTY heuristic, that Alan described, is insufficient.
>>
>> I can't find any other way, and we had multiple complaints when the
>> behaviour was broken whereas this is the first complaint in the other
>> direction that I've seen.
>>
>> If you find an alternative, please let us know.
> 
> As I wrote, if "--batch" opts out of this, I am happy. I should have
> used "--batch" right away in my program. Since this is what I am doing -
> I am starting a batch background worker job. I just wasn't aware of the
> opt-out. Hopefully the batch setting does not have other unexpected side
> effects.

Hmm, it seems that in my use case the combination of --batch and
--daemon is not working. This means I have to keep using --chdir for the
opt-out. I guess it is expected that --daemon and --batch cannot be
combined? My use case is kind of an edge case.

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

[Eli Zaretskii]

> Cc: alan@idiocy.org, 48579@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 14:54:26 +0200
> 
> > Right, no roadblocks.  And Emacs does determine that, for its own
> > purposes, on all platforms.  It just doesn't expose that to Lisp.
> 
> This statement does not seem correct to me. There is a default-directory
> which I can access in the initial *scratch* buffer. Something is exposed
> here.

We are mis-communicating.  All I'm saying is that this
default-directory is not (and doesn't have to be) the cwd of the Emacs
process.

> But this discussion here seems to be a bit off-track. My point here is
> that the current working directory determination on MacOS uses a
> heuristic, which is not correct. It incorrectly determines that Emacs
> has been launched from the finder or some other Mac GUI application and
> therefore changes the directory to the home directory. If Emacs is
> indeed started from the GUI, this makes all sense. But this is not the
> case here. The TTY heuristic, that Alan described, is insufficient.

I don't see why it matters what logic Emacs follows on macOS when its
starts, wrt the cwd of the Emacs process.

If you want to make sure that the default-directory of *scratch* is
the directory where Emacs was started, we could add such a feature (it
doesn't exists now, and relying on what you see on GNU/Linux means you
are relying on one particular implementation).  However, even if we do
introduce such a feature, that still won't tell you anything about the
cwd of the Emacs process.  If this latter aspect is what you really
care about, you will have to explain the rationale, because I don't
see how it could be important.

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

[Philipp]

> Am 22.05.2021 um 15:09 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
> If you want to make sure that the default-directory of *scratch* is
> the directory where Emacs was started, we could add such a feature (it
> doesn't exists now, and relying on what you see on GNU/Linux means you
> are relying on one particular implementation).  However, even if we do
> introduce such a feature, that still won't tell you anything about the
> cwd of the Emacs process.  If this latter aspect is what you really
> care about, you will have to explain the rationale, because I don't
> see how it could be important.
> 

The actual working directory as seen by the kernel/process should indeed be irrelevant.  What matters is that when processing command-line arguments in batch mode, Emacs behaves like other Unix tools in that it resolves relative filenames as relative to the working directory that was current when the process was started.  In other words, when executing

   emacs -Q -batch -eval '(print default-directory)'

from a shell, Emacs must always print a representation of the shell's current working directory (ignoring corner cases such as "default directory has been removed during process startup").  Guaranteeing that (a) when processing command-line arguments the *scratch* buffer is current (unless changed by a previous command-line argument), and (b) its default directory will be set to a representation of the initial process working directory should ensure that.  I guess that's already the case for all operating systems, and we only need to document it.