[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48579: 28.0.50; Spawning an emacs process using call-process results
From: |
Philipp |
Subject: |
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS |
Date: |
Sun, 23 May 2021 12:30:36 +0200 |
> 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.
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, (continued)
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Alan Third, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
- bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Daniel Mendler, 2021/05/22
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS, Eli Zaretskii, 2021/05/22
bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent, behavior between GNU/Linux and macOS,
Philipp <=