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

[Philipp <p.stephani2@gmail.com>]

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