GNU bug report logs - #24157
25.1.50; (princ "..." t) does not go to stderr in batch mode

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 24157 in the body.
You can then email your comments to 24157 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: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; (princ "..." t) does not go to stderr in batch mode
Date: Fri, 5 Aug 2016 01:29:15 -0400

[Message part 1 (text/plain, inline)]

Contrast this:

  $ emacs --batch --eval '(message "to stderr.")' > /dev/null
  to stderr.

With that (it produces no output):

  $ emacs --batch --eval '(princ "to stderr?" t)' > /dev/null

And yet according to the docs:

  Any Lisp program output that would normally go to the echo area,
  either using message, or using prin1, etc., with t as the stream, goes
  instead to Emacs’s standard error descriptor when in batch mode.
  -- https://www.gnu.org/software/emacs/manual/html_node/elisp/Batch-Mode.html

What am I doing wrong?
Clément.

In GNU Emacs 25.1.50.7 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-07-20 built on clem-w50-mint
Repository revision: a1a0c208e3e895a6ea0942e8e5c4077faf12c7ad
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Linux Mint 18 Sarah

[signature.asc (application/pgp-signature, attachment)]

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

From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
To: 24157 <at> debbugs.gnu.org
Subject: Re: bug#24157: Acknowledgement (25.1.50; (princ "..." t) does not go
 to stderr in batch mode)
Date: Fri, 5 Aug 2016 01:37:31 -0400

[Message part 1 (text/plain, inline)]

Also:

  $ emacs --batch --eval '(progn (message "to stderr.") (princ "to stderr?" t))' > /dev/null
  to stderr.
  $ emacs --batch --eval '(progn (princ "to stderr?" t) (message "to stderr."))' > /dev/null

  to stderr.

And worse:

  $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' > /dev/null

  to stderr.
  $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' 2> /dev/null
  to stdout!

(which I guess suggests that 'message' is the one adding the newline, not princ)

Clément.

On 2016-08-05 01:30, GNU bug Tracking System wrote:
> Thank you for filing a new bug report with debbugs.gnu.org.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  bug-gnu-emacs <at> gnu.org
> 
> If you wish to submit further information on this problem, please
> send it to 24157 <at> debbugs.gnu.org.
> 
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
> 

[signature.asc (application/pgp-signature, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
Cc: 24157 <at> debbugs.gnu.org
Subject: Re: bug#24157: 25.1.50;
 (princ "..." t) does not go to stderr in batch mode
Date: Fri, 05 Aug 2016 09:03:09 +0300

tags 24157 + notabug
thanks

> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Fri, 5 Aug 2016 01:29:15 -0400
> 
> Contrast this:
> 
>   $ emacs --batch --eval '(message "to stderr.")' > /dev/null
>   to stderr.
> 
> With that (it produces no output):
> 
>   $ emacs --batch --eval '(princ "to stderr?" t)' > /dev/null
> 
> And yet according to the docs:
> 
>   Any Lisp program output that would normally go to the echo area,
>   either using message, or using prin1, etc., with t as the stream, goes
>   instead to Emacs’s standard error descriptor when in batch mode.
>   -- https://www.gnu.org/software/emacs/manual/html_node/elisp/Batch-Mode.html
> 
> What am I doing wrong?

You are reading stale documentation.  The current (25.1RC1) manual
says this instead:

     Any Lisp program output that would normally go to the echo area,
  either using ‘message’, or using ‘prin1’, etc., with ‘t’ as the stream,
  goes instead to Emacs’s standard descriptors when in batch mode:
  ‘message’ writes to the standard error descriptor, while ‘prin1’ and
  other print functions write to the standard output.

OK to close this bug?

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

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24157: 25.1.50; (princ "..." t) does not go to stderr in
 batch mode
Date: Fri, 5 Aug 2016 03:11:59 -0400

[Message part 1 (text/plain, inline)]

On 2016-08-05 02:03, Eli Zaretskii wrote:
> OK to close this bug?

Thanks Eli. Sorry for the false alarm.

This means that the only way to write to stderr without a newline is (let ((cursor-in-echo-area t)) (message ...)), right? This is not ideal.

Also, I still think that this is an issue:

  $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' > /dev/null

  to stderr.
  $ emacs --batch --eval '(progn (message "to stderr.") (princ "to stdout!"))' > /dev/null
  to stderr.
  $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' 2> /dev/null
  to stdout!

If I read what you sent correctly, the first two rpograms should produce the same output, and the call to princ shouldn't cause 'message' to insert a newline before "to stderr.", right?

Clément.

[signature.asc (application/pgp-signature, attachment)]

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>
Cc: 24157 <at> debbugs.gnu.org
Subject: Re: bug#24157: 25.1.50;
 (princ "..." t) does not go to stderr in batch mode
Date: Fri, 05 Aug 2016 10:20:24 +0200

On Fr, Aug 05 2016, Clément Pit--Claudel <clement.pit <at> gmail.com> wrote:

> This means that the only way to write to stderr without a newline is (let ((cursor-in-echo-area t)) (message ...)), right? This is not ideal.

Use external-debugging-output.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>
Cc: 24157 <at> debbugs.gnu.org
Subject: Re: bug#24157: 25.1.50;
 (princ "..." t) does not go to stderr in batch mode
Date: Fri, 05 Aug 2016 16:52:20 +0300

> From: Clément Pit--Claudel <clement.pit <at> gmail.com>
> Date: Fri, 5 Aug 2016 03:11:59 -0400
> 
> This means that the only way to write to stderr without a newline is (let ((cursor-in-echo-area t)) (message ...)), right? This is not ideal.

No, you also have external-debugging-output (as pointed out by
Andreas) and append-to-file.

> Also, I still think that this is an issue:
> 
>   $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' > /dev/null
> 
>   to stderr.
>   $ emacs --batch --eval '(progn (message "to stderr.") (princ "to stdout!"))' > /dev/null
>   to stderr.
>   $ emacs --batch --eval '(progn (princ "to stdout!") (message "to stderr."))' 2> /dev/null
>   to stdout!
> 
> If I read what you sent correctly, the first two rpograms should produce the same output, and the call to princ shouldn't cause 'message' to insert a newline before "to stderr.", right?

No, what you see is deliberate behavior, intended to avoid mixing
output to stdout and stderr, when they are connected to the same
device.  You have redirected stdout, so the result looks surprising,
but that behavior is explicitly coded in Emacs (grep the C sources for
noninteractive_need_newline).

Previous Next

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