Jim Porter <jporterbugs@gmail.com> writes:

> On 7/5/2024 9:12 PM, Thierry Volpiatto wrote:
>>              (cond
>>               ((with-current-buffer bufname
>>                  (and (null eshell-foreground-command)
>>                       (null eshell-background-commands)))
>>                ;; The old buffer is done executing; kill it so we can
>>                ;; take its place.
>>                (kill-buffer bufname))
>> What if user ran a serie of commands and want to see the output of
>> each
>> one?
>
> I did that to preserve the logic of 'shell-command': if there's no
> running process in the buffer, it will get reused. That's the
> Eshell-ified analogue to this bit in 'shell-command':
>
> 	      ;; Ask the user what to do with already running process.
> 	      (when proc  ;; <-- This line.
> 		(cond
> 		 ((eq async-shell-command-buffer 'confirm-kill-process)
>                   ...
>
> Is that always what users want?

I don't think so, I for one prefer keeping the buffers around to see the
output of each commands:
If I run:

com1 &
com2 &
com3 &

I expect 

*buf* <=> com1
*buf<1>* <=> com2
*buf<2>* <=> com3

What if com3 overwrite *buf* where com1 exited with error, I have no
clue of what happened to com1.

I can't retrieve the initial bug report of Christopher, IIRC he was
describing his workflow running several shell commands, don't remember
if he had to examine each process buffer.  Christopher?

> Hard to say. Still, I think behaving like 'shell-command' is a good
> thing in order to follow the principle of least surprise.

Yes but following exactly what 'shell-command' does prevents improving both.

> (If we changed the behavior in 'eshell-command', I think we'd want to
> do the same in 'shell-command' too.)
>
> For users who *do* want something like that behavior, I think there
> are two options:
>
> 1. You could redirect the output in the Eshell command you enter at
> the prompt. For example:
>
>   do-something &> (generate-new-buffer "mybuf") &
>
> That would put the output from "do-something" into a unique buffer,
> running it asynchronously. (It wouldn't display the buffer by default,
> though with a bit of Elisp you could make it do that too.)
>
> 2. We could patch 'eshell-command' to be more like 'shell-command',
> and have a signature like:
>
>   (defun eshell-command (command &optional output-buffer error-buffer)
>     ...)
>
> That way, you could output to a unique buffer (or any Eshell target,
> in fact) by passing it as an argument. I have a WIP patch to add this.

In both options, IMHO it is to much to write in addition of the shell
command itself.

-- 
Thierry