Output error is not checked for some builtins (at least pwd and ulimit),
e.g. after closing stdout.

$ exec >&-
$ for i in echo pwd print ulimit; do echo "[$i]" >&2; $i; echo $? >&2; done
[echo]
1
[pwd]
0
[print]
1
[ulimit]
0

Note also that for pwd, POSIX[*] says:

  If an error is detected, output shall not be written to standard
  output, a diagnostic message shall be written to standard error,
  and the exit status is not zero.

so that one would expect a diagnostic message (and I think that
one should also get one for the other builtins).

[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pwd.html

retitle 990265 mksh: output error is not checked for some builtins when stdout is closed
# notabug
close 990265
thanks

Vincent Lefevre dixit:

You have just left POSIX land:

   At program start-up, three streams are predefined and need not be
   opened explicitly: standard input (for reading conventional input),
   standard output (for writing conventional output), and standard error
   (for writing diagnostic output). When opened, the standard error
   stream is not fully buffered; the standard input and standard output
   streams are fully buffered if and only if the stream can be
   determined not to refer to an interactive device.

At the start of those commands, stdout is closed, so you violate that
constraint. Note POSIX is not just demands on the implementation but
also on the user, for example, it specifically permits extensions where
the behaviour is otherwise unspecified, i.e. which could not happen in
a conforming user.

Compare the second paragraph of https://mywiki.wooledge.org/FileDescriptor
and we’ve had a number of issues over the years, first reported by Jerker
Bäck, with closed stdout and stderr in various utilities finding that this
is not support{ed,able} at all.

Pretty sure closed stdout is not an what they had in mind for that
utility.

Cc’ing; I can’t decide for aweeraman, but this is not a bug in mksh.

bye,
//mirabilos

retitle 990265 mksh: output error is not checked for some builtins
reopen 990265
thanks
[...]

Note that here, pwd is a builtin, so that there is no
"program start-up". So no constraints are violated.

Anyway, this was just an example. So, instead of a closed stdout,
let's write to a full file system:

$ pwd > /dev/full
$ echo $?
0
$ /bin/pwd > /dev/full
/bin/pwd: write error: No space left on device
$ echo $?
1

With the mksh builtin, the error is not detected.

Whatever POSIX says, it is important to report an error in such
a case, at least for the robustness of scripts.

Same problem with ksh93.

retitle 990265 mksh: output error is not checked for some builtins
reopen 990265
thanks

Another example (due to the "sleep 1", the "true" has normally
terminated when pwd is executed):

$ { trap '' PIPE; sleep 1; pwd; echo $? >&2; } | true
0

both with mksh and ksh93.

With dash:

$ { trap '' PIPE; sleep 1; pwd; echo $? >&2; } | true
sh: 1: pwd: pwd: I/O error
1

close 990265
thanks

Vincent Lefevre dixit:

This is wrong. pwd is allowed to be a builtin or not, and
POSIX is pretty specific in that this shall not make a difference.

These are all user errors.

Perhaps. But unless required by POSIX, I’m not going to do the
work. Utilities can, in general, assume that the standard I/O
streams work properly or it is either a user error or one they
cannot do much about anyway, and not catching errors on write(2),
printf(3), etc. is s̲o̲ common in the Unix world you’ll have to
live with it. In almost all cases, there’s also nothing one can
do about it.

For pwd(1) especially, I can argue that failure to write the
result is not actually an error. It determined the directory
properly and sent the information out. I’d argue that making
failure to write into an error for pwd(1) is a bug.

bye,
//mirabilos

close 990264
thanks

There was an update on this from the Austin Group that will be in the
next version of the POSIX standard relating to the streams that need
to be opened at startup. Here's the changed verbiage which is explicit
about the streams needing to be "already open":

"At program start-up, three streams shall be predefined and already open:
stdin (standard input, for conventional input) for reading, stdout
(standard output, for conventional output) for writing, and stderr
(standard error, for diagnostic output) for writing." [1]

Also, some more elaboration by POSIX on unspecified behavior if the
standard streams are not open for reading and writing:

"If a standard utility or a conforming application is executed with file
descriptor 0 not open for reading or with file descriptor 1 or 2 not
open for writing, the environment in which the utility or application
is executed shall be deemed non-conforming, and consequently the utility
or application might not behave as described in this standard." [2]

[1] - https://austingroupbugs.net/view.php?id=1347#c5161
[2] - https://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html

Anuradha Weeraman dixit:

Isn’t this what I already found in the online docs?

Ah, a clarification then. Very good! Thanks for spotting this.

Ah, good to know; this explicitly confirms that this is not a bug.
I should have looked there.

bye,
//mirabilos

reopen 990264
reopen 990265
thanks

because the result of "pwd > /dev/full" is non POSIX conforming.

See the message from Don Cragun in the Austin Group list, which says:

Section 1.4 of the Commands and Utilities Volume of the standard
(Utility Description Defaults) already does this in the CONSEQUENCES
OF ERRORS section on P2303-2304, L74122-74151 in P1003.1-202x Draft 2
and on P2341-2342, L74540-74569 in P1003.1-2017.  Note especially:
    The following shall apply to each utility, unless
    otherwise stated:
        ... ... ...
        • When an unrecoverable error condition is
          encountered, the utility shall exit with a
          non-zero exit status.
        • A diagnostic message shall be written to
          standard error whenever an error condition
          occurs.
[...]

OK, but as said, that was just an example. There are other cases of
write errors, which correspond to valid conditions, such as when the
filesystem is full (see above).

tags 990265 + moreinfo
outlook 990265 let's fight this out on the Austin mailing list
thanks

Vincent Lefevre dixit:

I'm still not convinced, but let's take this elsewhere then until
we have some definite statements us shell maintainers can actually
comprehend and follow.

If you wish to do me a favour, collect all of them, so I can fix
them if necessary, as I really do not have the tuits to do so.

Thanks,
//mirabilos

reassign -1 ksh93u+m
found -1 1.0.4-3
found -1 1.0.8-1
tag -1 upstream
forwarded -1 https://github.com/ksh93/ksh/issues/313

Forgot the "Control:".

Also: note the reassign due to the package rename of ksh to ksh93u+m
in September 2021. 1.0.4-3 is the current stable, and 1.0.8-1 the
current unstable version.