Re: Use of "negative" in pow() ERRORS (was: [1003.1(2016/18)/Issue7+TC2 0001302]: Alignment with C17)

On 2020-11-12 10:05:16 +, Geoff Clare via austin-group-l at The Open Group wrote: > The problem is that the phrase "negative zero" is commonly used to > mean -0.0, so some people naturally assume that "negative" on its > own includes "negative zero". In the IEEE 754-2019 standard, "negative

Re: Use of "negative" in pow() ERRORS (was: [1003.1(2016/18)/Issue7+TC2 0001302]: Alignment with C17)

On 2020-11-09 09:39:25 +, Geoff Clare via austin-group-l at The Open Group wrote: > I believe this is a misuse of "negative". The RETURN VALUE section > says "For finite values of x < 0, and finite non-integer values of y, > a domain error shall occur ..." > > So the ERRORS section should

utilities and write errors

Shouldn't POSIX require that when a utility cannot write its output (e.g. due to ENOSPC or EPIPE), it shall be regarded as an error, i.e. the exit status be non zero, with a diagnostic message if possible? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML -

Re: utilities and write errors

On 2021-07-05 13:53:45 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Once again, buffering exists and is known to exist - and what's more, > the standard actually *required* stdout to be buffered whenever it is > not associated with a terminal (which is no big surprise, as

Re: utilities and write errors

On 2021-06-29 14:11:45 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group: > [...] > > > If in general, then forget it - the users would lynch you (you'd probably > > > suicide first) if you

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 09:31:11 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > I would say the standard is unclear. To me the most reasonable > interpretation of "The expression evaluates to null or zero" is > that it evaluates to either a null string or a zero-valued integer. >

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 14:30:44 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > > With busybox expr (version 1.30.1), I get: > > > > $ busybox expr 0 ; echo $? > > 0 > > 1 > > $ busybox expr -0 ; echo $? > > -0 > > 0 > > $ busybox expr "" \| -0 ; echo $? > > -0 > > 0 > > $ busybox expr

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 10:54:30 +, shwaresyst via austin-group-l at The Open Group wrote: > To the extent XBD 11.1, #6 applies I suppose you mean 12.1 (Utility Argument Syntax). But #6 says "Unless otherwise specified", which is the case for expr, which explicitly says when the argument is read as a

Re: utilities and write errors

On 2021-06-29 22:43:49 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Date:Tue, 29 Jun 2021 09:49:40 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210629084940.GA8391@localhost> > > | You are wrong when you

Re: utilities and write errors

On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group > wrote: > > Don Cragun via austin-group-l at The Open Group dixit: > > > > > • When an unrecoverable error condition is > > > encountered, the utility shall exit with

Re: utilities and write errors

On 2021-06-30 00:46:00 +, mirabilos via austin-group-l at The Open Group wrote: > Using the same shorthand, I changed mksh tonight to do pretty much > what you described, in a second patch: > > @@ pseudo @@ > int > call_builtin(func_t builtinfunc, int argc, char *argv[]) > { > int

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open > Group: > [...] > > > ( > > > sleep 1 > > > set +o errexit -o xtrace > > > p

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > But utilities are meant to behave the same whether they're > builtin or not. A non-builtin pwd writting to a closed pipe > would not cause the shell to exit. Another difference between implementations

Re: utilities and write errors

On 2021-06-29 20:59:51 -0700, L A Walsh wrote: > On 2021/06/29 17:55, Vincent Lefevre wrote: > > On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > > > --- > > >No. the pwd utility has had its stdout redirected by its > > > parent, "the shell". Since the faulty redirection was done by parent, >

Re: utilities and write errors

On 2021-06-28 20:01:03 +0700, Robert Elz via austin-group-l at The Open Group wrote: > if a utility is invoked with any of stdin/out/err closed then what happens > is very explicitly unspecified in POSIX. My guess is that that is largely > because if the utility then opens a file it will be

Re: utilities and write errors

On 2021-06-28 22:02:22 +, tg...@mirbsd.org via austin-group-l at The Open Group wrote: > What’s currently left of Vincent’s issue is that the utility tries > to write to its stdout¹ which the shell has connected to something > that does not accept writes: /dev/full on systems that have it, an

Re: utilities and write errors

On 2021-06-28 21:28:37 +0700, Robert Elz wrote: > Date:Mon, 28 Jun 2021 15:48:33 +0200 > From:Vincent Lefevre > Message-ID: <20210628134833.ga46...@zira.vinc17.org> > > | So, if writing to a closed fd yields unspecified behaviour, what > | does "refers to no open

Re: utilities and write errors

I forgot another useful case with write error checking. For instance, I expect the following command to terminate, which is not the case with ksh: ( trap '' PIPE; while pwd; do :; done; ) | head Worse, with ksh93, when I hit Ctrl-C to interrupt this command, a ksh93 process is still running,

Re: utilities and write errors

On 2021-07-07 00:48:28 +0700, Robert Elz via austin-group-l at The Open Group wrote: > | > Implementor of what? > | Of pwd. > > Who has no idea whether or not buffering is being used. When using stdio, the implementor knows that buffering *may* be used. Thus he needs to call fflush at the

Re: utilities and write errors

On 2021-07-13 22:37:55 +0700, Robert Elz via austin-group-l at The Open Group wrote: > We'll start with the EXIT STATUS section of cd: > > 82508 >0 Either the -e option or the -P option is not in effect, and an error > occurred. > 82511 >1 Both the -e and the -P options are in effect, and an

pwd and CONSEQUENCES OF ERRORS

https://austingroupbugs.net/view.php?id=1488 about pwd and CONSEQUENCES OF ERRORS considers ENOSPC only. But are there other errors that may yield a partial write? I'm thinking of EFBIG and EPIPE, in particular. -- Vincent Lefèvre - Web: 100% accessible validated

Re: Posix issue 8 pending change to system().

On 2021-10-23 22:57:09 -0500, Rob Landley via austin-group-l at The Open Group wrote: > On 10/23/21 8:39 PM, Vincent Lefevre wrote: > > On 2021-10-23 18:08:37 -0500, Rob Landley via austin-group-l at The Open > > Group wrote: > >> Testing: > >> > >> $ bash -c '-i echo hello' > >> bash: - :

Behavior of "sh -c +c"

On 2021-10-30 14:33:04 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > POSIX ended up mandating that bug (mandating that system("+c") > should run an interactive shell for instance), because, like the > the Unix libc implementors, they overlooked the issue. It is > clearly

Re: Behavior of "sh -c +c"

On 2021-11-03 16:41:40 +, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-11-03 17:06:07 +0100, Vincent Lefevre via austin-group-l at The Open > Group: > [...] > > ksh93 and mksh run an interactive shell, but I wonder whether this > > should

Re: asctime and ctime

On 2021-10-23 08:53:06 -0700, Scott Lurndal via austin-group-l at The Open Group wrote: > On Sat, Oct 23, 2021 at 01:51:15PM +0200, Vincent Lefevre via austin-group-l > at The Open Group wrote: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html > >

Re: Posix issue 8 pending change to system().

On 2021-10-23 18:08:37 -0500, Rob Landley via austin-group-l at The Open Group wrote: > Testing: > > $ bash -c '-i echo hello' > bash: - : invalid option > $ dash -c '-i echo hello' > dash: 0: Illegal option - > # android > $ sh -c "-i echo hello" > sh: sh: - : unknown option > >

behavior of fgets in case of a read error

POSIX does not say anything about the contents of the array in case of a read error with fgets. ISO C17 says "the array contents are indeterminate" and N2861 says "the members of the array have unspecified values". In both cases, this is a bit unintuitive concerning s[n-1], as one may get a value

Re: utilities and write errors

On 2021-07-25 09:16:16 +0700, Robert Elz via austin-group-l at The Open Group wrote: > I say that pwd must write to standard output, but that nothing says that > that write must actually succeed - because there simply is no text that > requires that (if there were, someone would have quoted it by

sh and .profile in Issue 7

In Issue 7, there are a few references to the .profile file: * Page 2344 line 74642: Uses of files as command scripts, or for configuration or control, are exempt. For example, it is not required that sh be able to read an arbitrarily large .profile. * Page 3308 line 111414:

behavior of the QUIT character (^\) in the shell command line

What is the behavior of the QUIT character (^\) when typing a command in an interactive sh shell? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html just says that if the shell is interactive, SIGQUIT shall be ignored. Results with various POSIX and non-POSIX shells: With bash

Re: behavior of the QUIT character (^\) in the shell command line

On 2022-12-18 08:27:31 +0700, Robert Elz wrote: > | https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html just > | says that if the shell is interactive, SIGQUIT shall be ignored. > > That just means that the shell doesn't exit with a core dump when the > signal is generated

Re: sh 'continue' shenanigans: negating

On 2024-02-15 10:54:09 +0700, Robert Elz via austin-group-l at The Open Group wrote: > I suspect you're confusing exit status and the ? special param - they're > not the same thing. Every utility, and the shell compound commands, have > an exit status. What actually appears in ? is specified,

Re: behavior of test ! = -o ! ''

On 2024-04-03 16:43:42 +0200, Vincent Lefevre wrote: > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html > says for >4 arguments with XSI: > > In addition, the string comparison binary primaries '=' and "!=" > shall have a higher precedence than any unary primary. > >

behavior of test ! = -o ! ''

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html says for >4 arguments with XSI: In addition, the string comparison binary primaries '=' and "!=" shall have a higher precedence than any unary primary. (note the "shall"). So, what about the following command? test ! =

Re: behavior of test ! = -o ! ''

On 2024-04-03 16:57:50 +0200, Vincent Lefevre wrote: > However, same question for > > test -e = -o ! '' > > Here, with ksh93u+m 1.0.8-1 under Debian: > > $ test -e = -o ! '' ; echo $? > > 1 > > which I think it is wrong (with any meaning, I