GNU bug report logs - #17390
24.4.50; Doc bug: 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 17390 in the body.
You can then email your comments to 17390 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: Johan Bockgård <bojohan <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; Doc bug: Batch Mode
Date: Fri, 02 May 2014 20:11:37 +0200

(info "(elisp) Batch Mode") says:

    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.

This is not correct. Text printed with "`prin1', etc., with `t' as the
stream" goes to stdout, not stderr. (Unlike `message'.)

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

From: Glenn Morris <rgm <at> gnu.org>
To: Johan Bockgård <bojohan <at> gnu.org>
Cc: 17390 <at> debbugs.gnu.org
Subject: Re: bug#17390: 24.4.50; Doc bug: Batch Mode
Date: Fri, 02 May 2014 19:42:57 -0400

Johan Bockgård wrote:

> This is not correct. Text printed with "`prin1', etc., with `t' as the
> stream" goes to stdout, not stderr. (Unlike `message'.)

To me, it would make more sense for `message' to use stdout too.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 17390 <at> debbugs.gnu.org
Subject: Re: bug#17390: 24.4.50; Doc bug: Batch Mode
Date: Sun, 06 Sep 2015 23:52:00 +1200

Johan Bockgård <bojohan <at> gnu.org> writes:
> (info "(elisp) Batch Mode") says:
>
>     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.
>
> This is not correct. Text printed with "`prin1', etc., with `t' as the
> stream" goes to stdout, not stderr. (Unlike `message'.)


Glenn Morris <rgm <at> gnu.org> writes:
> To me, it would make more sense for `message' to use stdout too.


This bug is still in effect (although it's not clear to me that the
documentation should be considered to be what is in error?)

It does seems initially intuitive that `message' would go to stdout,
but having it go to stderr certainly makes more sense in the context
of what the documentation claims -- that output written to the echo
area (eq PRINTCHARFUN t) is treated as stderr.

At present, `message' seems to be the *only* way of getting output to
stderr in batch mode, which isn't ideal, as you don't get the same
choice of output formats that you have with all the prin* functions.

e.g. The documentation suggests that (princ "foo\n") would write to
stdout, and (princ "foo\n" t) would write to stderr, which would seem
useful, and much nicer than everything except `message' writing to
stdout.


However I do note that the functions accepting a PRINTCHARFUN argument
tend to say that it will, when `nil', default to the value of
`standard-output'; and that latter value (whether in batch mode or
not) defaults to `t' -- precisely what is supposed to mean stderr!


As such, this seems a bit messy; but given that the bug looks to have
been in effect for quite a while now (23.4 behaves the same way), I
wonder whether it would be sensible at this point to provide a
completely new option for PRINTCHARFUN which explicitly means stderr
(or indirectly, via a new `standard-error' variable, seeing as how we
have both `standard-input' and `standard-output' vars, but no -error).

That way we'd regain(??) the ability to send arbitrary prin* output
to stderr in batch mode, without messing with the existing behaviour.


Whether or not `message' continued to write to stderr would be a
separate question, and I'm not sure what the right answer is, but it
would certainly be a backwards-incompatible change.

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

From: Johan Bockgård <bojohan <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 17390 <at> debbugs.gnu.org
Subject: Re: bug#17390: 24.4.50; Doc bug: Batch Mode
Date: Sat, 31 Oct 2015 22:52:44 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

> I wonder whether it would be sensible at this point to provide a
> completely new option for PRINTCHARFUN which explicitly means stderr

It exists and is called `external-debugging-output'.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Johan Bockgård <bojohan <at> gnu.org>
Cc: 17390 <at> debbugs.gnu.org
Subject: Re: bug#17390: 24.4.50; Doc bug: Batch Mode
Date: Sat, 10 Feb 2018 09:47:21 -0500

tags 17390 fixed
close 17390 25.1
quit

Johan Bockgård <bojohan <at> gnu.org> writes:

> (info "(elisp) Batch Mode") says:
>
>     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.
>
> This is not correct. Text printed with "`prin1', etc., with `t' as the
> stream" goes to stdout, not stderr. (Unlike `message'.)

This was fixed in 25.1.

[1: 565adf2e90]: 2018-02-08 20:32:47 -0500
  Clarify that text-quoting-style doesn't affect *Info* (Bug#24519)
  [...]
  (Batch Mode): Document how text written to standard streams is
encoded.  Fix inaccuracy regarding which output streams are used
by output functions in batch mode.
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=565adf2e90d67de2107343aaf265ec6c3e8fd165

Previous Next

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