bug#67637: shell-command-default-error-buffer loss of warning

bug#67637: shell-command-default-error-buffer loss of warning

[Dan Jacobson]

(Never mind https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67542 .
I have found the real problem.)

$ emacs -Q --eval '(setq shell-command-default-error-buffer "shell-command-errors")'
M-! ls zzzzzzzz
(Shell command failed with code 2 and some error output to the "shell-command-errors" buffer)

OK, we now grow to expect that we will get helpful notification that
something about "some error output to the "shell-command-errors"
buffer". That's great.

Until one day when we instead do
M-! ls .emacs zzzzzzzz #one file that exists and one that doesn't

In this case the bug steps in:
Even though there indeed is
"some error output to the "shell-command-errors"
but there is no message in the minibuffer about it!

That indeed there is also some STDOUT produced does *not* mean
we somehow are in some party mood and no longer care about the fact that
indeed the same complete
"Shell command failed with code 2 and some error output to the "shell-command-errors" buffer"
is 100% still true.

One might think that "oh, that's just the one line successful output
covering up the error message in the minibuffer." But the same problem
occurs with
M-! ls . zzzzzzzz

bug#67637: shell-command-default-error-buffer loss of warning

[Eli Zaretskii]

tags 67637 wontfix
thanks

> From: Dan Jacobson <jidanni@jidanni.org>
> Date: Tue, 05 Dec 2023 10:27:51 +0800
> 
> (Never mind https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67542 .
> I have found the real problem.)
> 
> $ emacs -Q --eval '(setq shell-command-default-error-buffer "shell-command-errors")'
> M-! ls zzzzzzzz
> (Shell command failed with code 2 and some error output to the "shell-command-errors" buffer)
> 
> OK, we now grow to expect that we will get helpful notification that
> something about "some error output to the "shell-command-errors"
> buffer". That's great.
> 
> Until one day when we instead do
> M-! ls .emacs zzzzzzzz #one file that exists and one that doesn't
> 
> In this case the bug steps in:
> Even though there indeed is
> "some error output to the "shell-command-errors"
> but there is no message in the minibuffer about it!
> 
> That indeed there is also some STDOUT produced does *not* mean
> we somehow are in some party mood and no longer care about the fact that
> indeed the same complete
> "Shell command failed with code 2 and some error output to the "shell-command-errors" buffer"
> is 100% still true.
> 
> One might think that "oh, that's just the one line successful output
> covering up the error message in the minibuffer." But the same problem
> occurs with
> M-! ls . zzzzzzzz

All I can suggest is "don't do that".  Not unless you intend keeping
in mind that the error messages are in a separate buffer.

This option exists for special situations, not for general-purpose
running of shell commands that might produce some important
information on standard error stream.

I don't think we should do anything here.

bug#67637: shell-command-default-error-buffer loss of warning

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> All I can suggest is "don't do that".  Not unless you intend keeping
> in mind that the error messages are in a separate buffer.
>
> This option exists for special situations, not for general-purpose
> running of shell commands that might produce some important
> information on standard error stream.
>
> I don't think we should do anything here.

I'm therefore closing this bug report.