retitle 990265 mksh: output error is not checked for some builtins when stdout is closed # notabug close 990265 thanks
Vincent Lefevre dixit: >Like with ksh93, 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 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. >Note also that for pwd, POSIX[*] says: > > If an error is detected, output shall not be written to standard Pretty sure closed stdout is not an what they had in mind for that utility. >Note: Debian bug for ksh93: Cc’ing; I can’t decide for aweeraman, but this is not a bug in mksh. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
