* bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode
@ 2016-08-05 5:29 Clément Pit--Claudel
[not found] ` <handler.24157.B.147037498113506.ack@debbugs.gnu.org>
2016-08-05 6:03 ` bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Clément Pit--Claudel @ 2016-08-05 5:29 UTC (permalink / raw)
To: 24157
[-- Attachment #1.1: Type: text/plain, Size: 853 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24157: Acknowledgement (25.1.50; (princ "..." t) does not go to stderr in batch mode)
[not found] ` <handler.24157.B.147037498113506.ack@debbugs.gnu.org>
@ 2016-08-05 5:37 ` Clément Pit--Claudel
0 siblings, 0 replies; 6+ messages in thread
From: Clément Pit--Claudel @ 2016-08-05 5:37 UTC (permalink / raw)
To: 24157
[-- Attachment #1.1: Type: text/plain, Size: 1252 bytes --]
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@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 24157@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode
2016-08-05 5:29 bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode Clément Pit--Claudel
[not found] ` <handler.24157.B.147037498113506.ack@debbugs.gnu.org>
@ 2016-08-05 6:03 ` Eli Zaretskii
2016-08-05 7:11 ` Clément Pit--Claudel
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2016-08-05 6:03 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 24157
tags 24157 + notabug
thanks
> From: Clément Pit--Claudel <clement.pitclaudel@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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode
2016-08-05 6:03 ` bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode Eli Zaretskii
@ 2016-08-05 7:11 ` Clément Pit--Claudel
2016-08-05 8:20 ` Andreas Schwab
2016-08-05 13:52 ` Eli Zaretskii
0 siblings, 2 replies; 6+ messages in thread
From: Clément Pit--Claudel @ 2016-08-05 7:11 UTC (permalink / raw)
To: 24157
[-- Attachment #1.1: Type: text/plain, Size: 828 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode
2016-08-05 7:11 ` Clément Pit--Claudel
@ 2016-08-05 8:20 ` Andreas Schwab
2016-08-05 13:52 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2016-08-05 8:20 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 24157
On Fr, Aug 05 2016, Clément Pit--Claudel <clement.pit@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode
2016-08-05 7:11 ` Clément Pit--Claudel
2016-08-05 8:20 ` Andreas Schwab
@ 2016-08-05 13:52 ` Eli Zaretskii
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2016-08-05 13:52 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 24157
> From: Clément Pit--Claudel <clement.pit@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).
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-08-05 13:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-05 5:29 bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode Clément Pit--Claudel
[not found] ` <handler.24157.B.147037498113506.ack@debbugs.gnu.org>
2016-08-05 5:37 ` bug#24157: Acknowledgement (25.1.50; (princ "..." t) does not go to stderr in batch mode) Clément Pit--Claudel
2016-08-05 6:03 ` bug#24157: 25.1.50; (princ "..." t) does not go to stderr in batch mode Eli Zaretskii
2016-08-05 7:11 ` Clément Pit--Claudel
2016-08-05 8:20 ` Andreas Schwab
2016-08-05 13:52 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.