GNU bug report logs -
#71049
async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"
Previous Next
Reported by: Dmitry Gutov <dmitry <at> gutov.dev>
Date: Sun, 19 May 2024 00:20:02 UTC
Severity: normal
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 19/05/2024 09:17, Eli Zaretskii wrote:
>> Date: Sun, 19 May 2024 03:19:00 +0300
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> Previously mentioned in bug#70901.
>>
>> When a Tramp connection is configured as "direct-async-process",
>>
>> 1. If the buffer*Async Shell Command* does not exist, invoking M-& in a
>> remote buffer from that connection makes it end with
>>
>> Process*Async Shell Command* finished
>>
>> The command can be simple, like 'ls' or 'echo 123'. I also see this
>> added to*Messages*:
>>
>> Tramp: Inserting
>> ‘/ssh:dgutov <at> fencepost.gnu.org:/home/d/dgutov/.tramp_history’...done
>>
>> Which seems odd (tramp history is re-read every time like this, for some
>> purpose?).
>>
>> 2. If the buffer such named already exists when command is invoked, then
>> this doesn't happen (the output seems correct). But*Messages* says
>>
>> -l: finished.
>>
>> ...which is a big puzzling as well.
>>
>> Also, scenario 1 (when the buffer doesn't exist yet) takes longer than
>> 2, but that might be a side-effect of implementation external to Tramp.
> The "finished" message comes from the default process sentinel, so if
> Tramp wants to avoid that, it should install its own sentinel.
shell-commands inserts a sentinel: shell-command-sentinel. So it never
inserts that message when invoked locally.
Even if it did, the disparity between the two scenarios would still be
something to investigate, I think.
This bug report was last modified 1 year and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.