GNU bug report logs - #71049
async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"

Previous Next

Full log

Message #41 received at 71049 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 71049 <at> debbugs.gnu.org
Subject: Re: bug#71049: async-shell-command ends with "Process *Async Shell
 Command* finished" when remote "direct-async-process"
Date: Fri, 24 May 2024 22:20:45 +0300

On 24/05/2024 21:55, Eli Zaretskii wrote:
>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: dmitry <at> gutov.dev,  71049 <at> debbugs.gnu.org
>> Date: Fri, 24 May 2024 18:39:21 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> Can you explain the effect of that option on the scenarios that
>>> started this bug report?  I don't think I have a clear understanding
>>> of that.
>>
>> We're speaking about shell-mode. Let's try the command
>> [...]
>> 6 roundtrips to insert the remote history file into a buffer which we
>> don't need. Just for a single asynchronous "ls" command.
>>
>> With the new user option, this could be avoided by a user setting.
> 
> Thanks.  But that's not what I thought I was asking about, see below.
> 
> However, as long as we are talking about reading the history file: why
> does async-shell-command need the history file?  (I understand why
> shell-mode does, but async-shell-command is not shell-mode.)

The answer is that async-shell-command uses shell-mode as the major mode 
for the output buffer. For syntax highlighting, I guess.

You make a good point that the shell history for such buffers would 
usually make no sense - even if the running process takes user input 
(usually not, but sometimes it might) - its input history would be 
different from the shell.

So maybe we could just move the last form in shell-mode (which 
initializes comint-input-ring) to 'shell'

>>> Why is the process being called by such bogus names anyway?
>>
>> I don't understand. Which bogus names?
> 
> I thought this was about the original complaints, whtch started this
> bug report, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71049#5.
> The fact that the history file was being read sounded as a side issue,
> at least at first.  So my question was about these messages:
> 
>    Process *Async Shell Command* finished
>    -l: finished.
> 
> I thought the option you suggest is intended to make these "process
> names" be more reasonable.  I guess I am confused, and the discussion
> moved to the "side issue" of preventing the unnecessary reading of the
> history file?

These are two separate (but correlated) issues in one bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.