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

Previous Next

Full log

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.