Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-27 Thread Thorsten Glaser
tags 990265 + moreinfo outlook 990265 let's fight this out on the Austin mailing list thanks Vincent Lefevre dixit: >because the result of "pwd > /dev/full" is non POSIX conforming. I'm still not convinced, but let's take this elsewhere then until we have some definite statements us shell

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-27 Thread Vincent Lefevre
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

Bug#990264: Bug#990265: Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-27 Thread Thorsten Glaser
Anuradha Weeraman dixit: >"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]

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-27 Thread Anuradha Weeraman
close 990264 thanks On Thu, Jun 24, 2021 at 01:49:55PM +, Thorsten Glaser wrote: > 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

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-24 Thread Thorsten Glaser
close 990265 thanks Vincent Lefevre dixit: >Note that here, pwd is a builtin, so that there is no >"program start-up". So no constraints are violated. 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. >Anyway, this was

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-24 Thread Vincent Lefevre
retitle 990265 mksh: output error is not checked for some builtins reopen 990265 thanks On 2021-06-24 16:26:24 +0200, Vincent Lefevre wrote: > 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

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-24 Thread Vincent Lefevre
retitle 990265 mksh: output error is not checked for some builtins reopen 990265 thanks On 2021-06-24 13:49:55 +, Thorsten Glaser wrote: > 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

Bug#990264: Bug#990265: mksh: output error is not checked for some builtins when stdout is closed

2021-06-24 Thread Thorsten Glaser
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

Bug#990265: mksh: output error is not checked for some builtins

2021-06-24 Thread Vincent Lefevre
Package: mksh Version: 59c-8 Severity: normal 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 [echo] 1 [pwd] 0 [print] 1 [ulimit] 0 Note