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

[Daniel Mendler <mail@daniel-mendler.de>]

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.