[pro] Default behavior of standard output streams

Hello, there is a discrepancy amongst compilers on how the default output streams behave in some situations. Consider the following test case: (format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%") Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways: myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1 SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty) ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL. Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3. I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*. WDYT? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

On May 22, 2012, at 10:58 , Didier Verna wrote:
Hello,
there is a discrepancy amongst compilers on how the default output streams behave in some situations. Consider the following test case:
(format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%")
Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways:
myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1
SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty)
ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL.
Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3.
I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*.
WDYT?
I think this is the usual story. Behavior should be agreed upon, once the "platform" is given. MA -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

Didier Verna <didier@lrde.epita.fr> writes:
Hello,
there is a discrepancy amongst compilers on how the default output streams
s/compilers/implementations/
behave in some situations. Consider the following test case:
(format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%")
Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways:
myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1
SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty)
I agree.
ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL.
Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3.
I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*.
WDYT?
Those are not bugs. Those are unspecified, implementation dependent behaviors. Well *query-io* is somewhat informally specified, so we definitely could consider that it should use /dev/tty on systems providing it. AFAIK, /dev/tty is not POSIX (posix doesn't specify /dev/). So this specification would have to be restricted to systems providing /dev/tty or a similar feature. You should write a CDR, and then indeed ask vendors to implement it. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

On Tue, 22 May 2012 10:58:27 +0200, Didier Verna said:
Hello,
there is a discrepancy amongst compilers on how the default output streams behave in some situations. Consider the following test case:
(format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%")
Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways:
myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1
SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty)
ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL.
Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3.
I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*.
WDYT?
It's a feature request, not a bug (the ANSI standard even says that it is common for the initial values of *error-output* and *standard-output* be the same stream). IMHO, having two independently-buffered streams connected to the same underlying destination in the interactive case #1 is a recipe for confusion. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/

FWIW, for CMUCL whole story looks like this (from memory, so take this with a grain of salt) -- SBCL does the same, unsurprisingly. There are streams *STDIN*, *STDOUT*, *STDERR*, and *TTY*. If /dev/tty cannot be opened, *TTY* is simply (make-two-way-stream *stdin* *stdout*) *STANDARD-INPUT*, *STANDARD-OUTPUT*, and *ERROR-OUTPUT* start out as synonym streams for *STDIN*, *STDOUT*, *STDERR*. *TERMINAL-IO*, *QUERY-IO* and *DEBUG-IO* start out as synonym streams for *TTY*. Neither two-way-streams nor synonym streams get buffering of their own: anything written to them is immediately written to the underlying stream. It's not a perfect setup, but it's not half bad, IMO. Cheers, -- nikodemus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, As others have pointed out, this does not appear to be a bug with respect to the hyperspec. But in my opinion, those implementations which send *error-output* to the same place as *standard-output* on POSIX platforms do have a bug. There is a quite reasonable expectation for how stdout and stderr should behave on those platforms, and if a language implementation does not conform to that behavior, it seems like it can be considered a bug. Conformance with the hyperspec isn't the only standard for considering if some behavior is a bug, is it? - -Jason On 05/22/2012 10:58 AM, Didier Verna wrote:
Hello,
there is a discrepancy amongst compilers on how the default output streams behave in some situations. Consider the following test case:
(format *standard-output* "This goes to standard output.~%") (format *error-output* "This goes to error output.~%") (format *query-io* "This goes to query io.~%")
Now, launch you favorite Lisp on a terminal and load this file at startup in 3 different ways:
myfavoritelisp --the-load-option test.lisp myfavoritelisp --the-load-option test.lisp > log myfavoritelisp --the-load-option test.lisp > log 2>&1
SBCL and CMUCL behave in a way which I think is right: case #1: everything is printed on the terminal case #2: stdout goes in the file case #3: stdout and stderr go in the file (*query-io* stays on the tty)
ECL redirects the output of *query-io* in the file for cases #2 and #3. The behavior of stdout and stderr is the same as in SBCL and CMUCL.
Finally, LW, ACL, CLISP, CCL and ABCL redirect everything in the file in cases #2 and #3.
I'm ready to fill in bug reports for the last 6 compilers, but are these really bugs? I'm convinced that it is for stderr, but it may be arguable for *query-io*.
WDYT?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+8+U4ACgkQQlm6HDTMLyMbHgCg0EUxEl8GG+cPuE615mAdBmtr lxwAoPsYEW64qlmMHnvtyS0MDugKYlzV =/EIh -----END PGP SIGNATURE-----
participants (7)
-
Didier Verna
-
Ian Dalton
-
Jason S. Cornez
-
Marco Antoniotti
-
Martin Simmons
-
Nikodemus Siivola
-
Pascal J. Bourguignon