Default behavior of standard output streams

[Didier Verna]

Content preview: 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.~%") [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/684>


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?

[Marco Antoniotti]

Content preview: On May 22, 2012, at 10:58 , Didier Verna wrote: > > Hello,

Post by Didier Verna
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? > [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/685>

Hello,
there is a discrepancy amongst compilers on how the default output streams
(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
myfavoritelisp --the-load-option test.lisp
myfavoritelisp --the-load-option test.lisp > log
myfavoritelisp --the-load-option test.lisp > log 2>&1
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.

[Pascal J. Bourguignon]

Content preview: Didier Verna <didier-+R3Ik2xuP/***@public.gmane.org> writes: > Hello, > > there
is a discrepancy amongst compilers on how the default output > streams s/compilers/implementations/
[...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/686>

Post by Didier Verna
Hello,
there is a discrepancy amongst compilers on how the default output streams

s/compilers/implementations/

Post by Didier Verna
(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
myfavoritelisp --the-load-option test.lisp
myfavoritelisp --the-load-option test.lisp > log
myfavoritelisp --the-load-option test.lisp > log 2>&1
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.

Post by Didier Verna
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.

[Martin Simmons]

Hello, > > there is a discrepancy amongst compilers on how the default
(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?
[...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/687>

Hello,
there is a discrepancy amongst compilers on how the default output streams
(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
myfavoritelisp --the-load-option test.lisp
myfavoritelisp --the-load-option test.lisp > log
myfavoritelisp --the-load-option test.lisp > log 2>&1
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.

[Nikodemus Siivola]

Content preview: 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 [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.213.51 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/688>

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

[Jason S. Cornez]

Content preview: -----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.
[...]

Content analysis details: (0.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[66.111.4.29 listed in list.dnswl.org]
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/689>

-----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

Post by Didier Verna
Hello,
there is a discrepancy amongst compilers on how the default output
streams behave in some situations. Consider the following test
(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
myfavoritelisp --the-load-option test.lisp myfavoritelisp
--the-load-option test.lisp > log myfavoritelisp --the-load-option
test.lisp > log 2>&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?

[Ian Dalton]

Content preview: "Jason S. Cornez" writes: > Conformance with the hyperspec
isn't the only standard for considering > if some behavior is a bug, is it?
The principle of least surprise should be considered whenever possible, at
the least. [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(iain.dalton[at]gmail.com)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/690>

Post by Jason S. Cornez
Conformance with the hyperspec isn't the only standard for considering
if some behavior is a bug, is it?

The principle of least surprise should be considered whenever possible,
at the least.