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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: dmitry@gutov.dev,  71049@debbugs.gnu.org
> Date: Fri, 24 May 2024 18:39:21 +0200
> 
> Eli Zaretskii <eliz@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.)

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