GNU bug report logs - #67637
shell-command-default-error-buffer loss of warning

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 67637 in the body.
You can then email your comments to 67637 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: shell-command-default-error-buffer loss of warning
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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Jacobson <jidanni <at> jidanni.org>
Cc: 67637 <at> debbugs.gnu.org
Subject: Re: bug#67637: shell-command-default-error-buffer loss of warning
Date: Tue, 05 Dec 2023 14:36:39 +0200

tags 67637 wontfix
thanks

> From: Dan Jacobson <jidanni <at> 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.

Message #15 received at 67637-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67637-done <at> debbugs.gnu.org, Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#67637: shell-command-default-error-buffer loss of warning
Date: Fri, 22 Dec 2023 06:50:35 -0800

Eli Zaretskii <eliz <at> 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.

Previous Next

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