bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Daniel Mendler
Subject: 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 15:20:56 +0200

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]