Subject: bug#67637: closed (Re: bug#67637: shell-command-default-error-buffer loss of warning)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 22 Dec 2023 14:51:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
67637: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67637
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#67637: shell-command-default-error-buffer loss of warning
From: Stefan Kangas <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], Dan Jacobson <[email-masked]>
Date: Fri, 22 Dec 2023 06:50:35 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

Eli Zaretskii <[email-masked]> 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.

Subject: shell-command-default-error-buffer loss of warning
From: Dan Jacobson <[email-masked]>
To: [email-masked]
Date: Tue, 05 Dec 2023 10:27:51 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

(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