Re: What string representations of "zero" expr should consider as "zero"? (was Re: utilities and write errors)

[tg...@mirbsd.org via austin-group-l at The Open Group]

Geoff Clare via austin-group-l at The Open Group dixit:

>As far as implementation detail goes, obviously if pwd uses stdio
>buffering then in order to conform to the standard it must explicitly
>fflush(stdout) and check there was no write error before exiting.
>I see from later in the thread that mksh has now been patched to do
>exactly that. (Thanks Thorsten.)

Right (except mksh doesn’t use stdio, it has its own buffering thing
called shf from pdsh). It already flushed but didn’t check for write
errors. I hope the “if write error and exitstatus 0 exit 1 instead”
won’t break anything.

>Now that mksh has been changed, it would appear you are the only hold-out
>(of those who have participated in the discussion here).

Vincent opened the same bug against ksh93 in Debian, which currently
is ksh93u plus some Debian patches, not Martijn’s version, but no longer
ksh2020 either. Anuradha should probably consult with Martijn on this.
(See http://www.mirbsd.org/ksh-chan.htm for an attempt to collect info
on ksh variants with some other shells thrown in.)


Stephane Chazelas via austin-group-l at The Open Group dixit:

>expr has so many design flaws, maybe the best approach would be
>to remove it from the standard altogether.
>
>In practice, it can't be used reliably, and it's mostly
>redundant with awk (we'd need gawk's match() 3rd argument

Please don’t. It’s still more often available than awk on really
old systems, and e.g. autoconf tools (GNU configure) and some
testsuites (BSD ed, GNU CVS, …) often use it for string matches.

Perhaps it can’t be used reliably in all cases, but it’s still
widespread enough, and usable enough in enough cases, for it to
stay. Otherwise it’ll be removed, and users will end up having
to implement their tests for two tools, none of which is ubiquitous
enough (or compatible enough, when installed).


shwaresyst via austin-group-l at The Open Group dixit:

>Now if more implementations than not are treating a single argument

On MirBSD you get these:

tg@tglase-bsd:~ $ expr 00 '|' 1
1
tg@tglase-bsd:~ $ expr -0 ; echo $?
-0
1
tg@tglase-bsd:~ $ expr 0 ; echo $?
0
1
tg@tglase-bsd:~ $ expr "" \| -0 ; echo $?
-0
1
tg@tglase-bsd:~ $ expr "" \| 01 ; echo $?
01
0

This differs from GNU coreutils only in the place where Geoff said
the difference would be expected/correct.

OpenBSD’s probably behaves the same, unless they changed something
after my forking it.

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)

Re: sort -c/C and last-resort sorting

[Stephane Chazelas via austin-group-l at The Open Group]

2021-07-02 15:54:48 +0100, Geoff Clare via austin-group-l at The Open Group:
> Joerg Schilling wrote, on 02 Jul 2021:
> >
> > > > > sort: -:2: disorder: a,a
> > > > 
> > > > Try to use the POSIX sort variant to avoid the message.
> > > [...]
> > > 
> > > I suppose you mean the -C option, which
> > > still checks but doesn't output a diagnostics message.
> > 
> > No, I was referring to /usr/xpg4/bin/sort
> 
> That no longer exists in Solaris.  If Illumos still has it they
> should probably remove it (or make it a symlink to /usr/bin/sort).
[...]

Illumos sort doesn't seem to be suporting -C yet:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/sort/common/options.c#L76
(code not changed since 2005).

-- 
Stephane

Re: sort -c/C and last-resort sorting

[Joerg Schilling via austin-group-l at The Open Group]

"Geoff Clare via austin-group-l at The Open Group" 
 wrote:

> > No, I was referring to /usr/xpg4/bin/sort
> 
> That no longer exists in Solaris.  If Illumos still has it they
> should probably remove it (or make it a symlink to /usr/bin/sort).

OK, I checked the source and the only difference between both versions is te 
missing warning in /usr/xpg4/bin/sort.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

Re: sort -c/C and last-resort sorting

[Geoff Clare via austin-group-l at The Open Group]

Joerg Schilling wrote, on 02 Jul 2021:
>
> > > > sort: -:2: disorder: a,a
> > > 
> > > Try to use the POSIX sort variant to avoid the message.
> > [...]
> > 
> > I suppose you mean the -C option, which
> > still checks but doesn't output a diagnostics message.
> 
> No, I was referring to /usr/xpg4/bin/sort

That no longer exists in Solaris.  If Illumos still has it they
should probably remove it (or make it a symlink to /usr/bin/sort).

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: sort -c/C and last-resort sorting

[Joerg Schilling via austin-group-l at The Open Group]

Stephane Chazelas  wrote:

> 2021-07-02 14:07:17 +0200, Joerg Schilling via austin-group-l at The Open 
> Group:
> > "Stephane Chazelas via austin-group-l at The Open Group" 
> >  wrote:
> > 
> > > Is:
> > > 
> > > printf '%s\n' a,b a,a | sort -c -t, -k1,1
> > > 
> > > Meant to succeed or not?
> > > 
> > > It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
> > > confusing:
> > > 
> > > sort: -:2: disorder: a,a
> > 
> > Try to use the POSIX sort variant to avoid the message.
> [...]
> 
> I suppose you mean the -C option, which
> still checks but doesn't output a diagnostics message.

No, I was referring to /usr/xpg4/bin/sort

~A

/

Re: sort -c/C and last-resort sorting

[Geoff Clare via austin-group-l at The Open Group]

Stephane Chazelas wrote, on 02 Jul 2021:
>
> btw, it seems to me -C should be referenced in the EXIT STATUS
> section and in the -u description like for -c.

Yes, also in STDOUT.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

Re: sort -c/C and last-resort sorting

[Stephane Chazelas via austin-group-l at The Open Group]

2021-07-02 14:07:17 +0200, Joerg Schilling via austin-group-l at The Open Group:
> "Stephane Chazelas via austin-group-l at The Open Group" 
>  wrote:
> 
> > Is:
> > 
> > printf '%s\n' a,b a,a | sort -c -t, -k1,1
> > 
> > Meant to succeed or not?
> > 
> > It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
> > confusing:
> > 
> > sort: -:2: disorder: a,a
> 
> Try to use the POSIX sort variant to avoid the message.
[...]

I suppose you mean the -C option, which
still checks but doesn't output a diagnostics message.

btw, it seems to me -C should be referenced in the EXIT STATUS
section and in the -u description like for -c.

But the question here also stands for -C: should sort return
success or failure when a file is sorted according to the key
specification but not as per the last resort sort, and should -s
be added to the specification.

I'm personally happy with Geoff's answer on those.

-- 
Stephane

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

[Geoff Clare via austin-group-l at The Open Group]

Vincent Lefevre wrote, on 02 Jul 2021:
>
> 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 "" \| 01 ; echo $?
> > > 01
> > > 0
> > > 
> > > For -0 (2nd and 3rd results), the exit status 0 does not seem to be
> > > consistent with the exit status 1 of the 1st result.
> > 
> > The "-0" is treated as a string and is non-null,
> [...]
> 
> But why is "-0" treated as a string, but not "0" (first case)?
> This does not seem to be consistent: according to the rules,
> they should not be treated differently.

I agree it's not consistent.  You would think that if the "is it zero"
check relating to exit status is being applied to strings, it would
be done using strtol() or atol(), not strcmp(arg,"0").

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

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

[Vincent Lefevre via austin-group-l at The Open Group]

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 "" \| 01 ; echo $?
> > 01
> > 0
> > 
> > For -0 (2nd and 3rd results), the exit status 0 does not seem to be
> > consistent with the exit status 1 of the 1st result.
> 
> The "-0" is treated as a string and is non-null,
[...]

But why is "-0" treated as a string, but not "0" (first case)?
This does not seem to be consistent: according to the rules,
they should not be treated differently.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: sort -c/C and last-resort sorting

[Geoff Clare via austin-group-l at The Open Group]

Stephane Chazelas wrote, on 02 Jul 2021:
>
> Is:
> 
> printf '%s\n' a,b a,a | sort -c -t, -k1,1
> 
> Meant to succeed or not?
> 
> It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
> confusing:
> 
> sort: -:2: disorder: a,a
> 
> diagnostic and succeeds in NetBSD.
> 
> It succeeds with -s in all implementations that support that
> flag (all but Solaris in that list above).
> 
> By my reading, NetBSD is not compliant, as nothing says the
> last-resort whole-line comparison does not apply with -c/-C,
> though with implementations that don't support -s (or with the
> POSIX API that doesn't support -s though references it), it
> seems to be a more useful (and less surprising) interface.

I've always assumed that the intention for -c is to answer the
question "if I ran this command without -c would the output be 
the same as the input?"  So the NetBSD behaviour seems wrong
to me.

> Currently, with Solaris sort, it doesn't look like it's possible
> to check whether a file is already sorted on a given key.
> 
> Should -s be added to POSIX?

Seems like a useful addition - I would be in favour.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

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

[Vincent Lefevre via austin-group-l at The Open Group]

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 string and when
it is read as an integer.

Where the standard is not clear is the interpretation of the result,
but XBD 12.1 #6 covers operands and option-arguments only, not results.

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

IMHO, considering that "zero" mean "when the result is intepreted
as an integer", so that the comparison with 0 makes sense, is also
a reasonable interpretation.

> However, that would require "expr 0" to exit with status 0 (because
> the 0 argument is treated as a string in this case), which does not
> match existing practice.

The text about integer vs string seems to be rather recent.
In the 2008 edition, there was only:

  A string argument is an argument that cannot be identified as an
  integer argument or as one of the expression operator symbols shown
  in the OPERANDS section.

So it was clear that "expr 0" should exit with status 1.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Geoff Clare via austin-group-l at The Open Group]

Vincent Lefevre wrote, on 02 Jul 2021:
>
> 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.
> > However, that would require "expr 0" to exit with status 0 (because
> > the 0 argument is treated as a string in this case), which does not
> > match existing practice.
> 
> And what about "-0"?
> 
> With expr from GNU coreutils 8.32 under Debian, I get:
> 
> $ expr 0 ; echo $?
> 0
> 1
> $ expr -0 ; echo $?
> -0
> 1
> $ expr "" \| -0 ; echo $?
> 0
> 1
> $ expr "" \| 01 ; echo $?
> 01
> 0
> 
> Note that for the 3rd result, I would expect -0 instead of 0 to be
> consistent with the 2nd and 4th results.

Yes, that's what the standard requires, so another way it doesn't
match (some) existing practice. Solaris does the same.

> 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 "" \| 01 ; echo $?
> 01
> 0
> 
> For -0 (2nd and 3rd results), the exit status 0 does not seem to be
> consistent with the exit status 1 of the 1st result.

The "-0" is treated as a string and is non-null, so the zero exit is
what you would expect if "The expression evaluates to null or zero" is
interpreted as "The expression evaluates to either a null string or a
zero-valued integer".

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[Issue 8 drafts 0001476]: Missing '+' character in the second example explanation

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has a resolution that has been APPLIED. 
== 
https://austingroupbugs.net/view.php?id=1476 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1476
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: Applied
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.14 / printf 
Page Number:3086 
Line Number:104321 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1476#c5390 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2021-05-19 12:21 UTC
Last Modified:  2021-07-02 12:18 UTC
== 
Summary:Missing '+' character in the second example
explanation
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2021-05-19 12:21 kreNew Issue
2021-05-19 12:21 kreName  => Robert Elz  
2021-05-19 12:21 kreSection   => XCU 2.14 / printf
2021-05-19 12:21 krePage Number   => 3086
2021-05-19 12:21 kreLine Number   => 104321  
2021-06-21 09:26 geoffclare Note Added: 0005388  
2021-06-21 09:27 geoffclare Note Edited: 0005388 
2021-06-24 16:17 geoffclare Note Added: 0005390  
2021-06-24 16:18 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1476#c5390
2021-06-24 16:18 geoffclare Status   New => Resolved 
2021-06-24 16:18 geoffclare Resolution   Open => Accepted As
Marked
2021-06-24 16:18 geoffclare Tag Attached: issue8 
2021-06-24 16:26 geoffclare Note Edited: 0005390 
2021-07-02 12:18 geoffclare Status   Resolved => Applied 
==

Re: sort -c/C and last-resort sorting

[Joerg Schilling via austin-group-l at The Open Group]

"Stephane Chazelas via austin-group-l at The Open Group" 
 wrote:

> Is:
> 
> printf '%s\n' a,b a,a | sort -c -t, -k1,1
> 
> Meant to succeed or not?
> 
> It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
> confusing:
> 
> sort: -:2: disorder: a,a

Try to use the POSIX sort variant to avoid the message.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

sort -c/C and last-resort sorting

[Stephane Chazelas via austin-group-l at The Open Group]

Is:

printf '%s\n' a,b a,a | sort -c -t, -k1,1

Meant to succeed or not?

It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
confusing:

sort: -:2: disorder: a,a

diagnostic and succeeds in NetBSD.

It succeeds with -s in all implementations that support that
flag (all but Solaris in that list above).

By my reading, NetBSD is not compliant, as nothing says the
last-resort whole-line comparison does not apply with -c/-C,
though with implementations that don't support -s (or with the
POSIX API that doesn't support -s though references it), it
seems to be a more useful (and less surprising) interface.

Currently, with Solaris sort, it doesn't look like it's possible
to check whether a file is already sorted on a given key.

Should -s be added to POSIX?

Any opinion?

-- 
Stephane

[Issue 8 drafts 0001485]: It may be clearer to describe pthread_cond_timedwait in terms of pthread_cond_clockwait rather than the other way round

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has a resolution that has been APPLIED. 
== 
https://austingroupbugs.net/view.php?id=1485 
== 
Reported By:mikecrowe
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1485
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Applied
Name:   Mike Crowe 
Organization:
User Reference:  
Section:pthread_cond_clockwait 
Page Number:1563 
Line Number:51671-51684 
Final Accepted Text:See
https://austingroupbugs.net/view.php?id=1485#c5385 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2021-06-12 14:08 UTC
Last Modified:  2021-07-02 11:12 UTC
== 
Summary:It may be clearer to describe pthread_cond_timedwait
in terms of pthread_cond_clockwait rather than the other way round
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2021-06-12 14:08 mikecrowe  New Issue
2021-06-12 14:08 mikecrowe  Name  => Mike Crowe  
2021-06-12 14:08 mikecrowe  Section   =>
pthread_cond_clockwait
2021-06-12 14:08 mikecrowe  Page Number   => 1563
2021-06-12 14:08 mikecrowe  Line Number   => 51671-51684 
2021-06-17 15:57 nick   Note Added: 0005385  
2021-06-17 15:58 nick   Final Accepted Text   => See
https://austingroupbugs.net/view.php?id=1485#c5385
2021-06-17 15:58 nick   Status   New => Resolved 
2021-06-17 15:58 nick   Resolution   Open => Accepted As
Marked
2021-06-17 15:59 nick   Tag Attached: issue8 
2021-07-02 11:12 geoffclare Status   Resolved => Applied 
==

[Issue 8 drafts 0001448]: Misleading text in description of poll()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has a resolution that has been APPLIED. 
== 
https://austingroupbugs.net/view.php?id=1448 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1448
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: Applied
Name:   Robert Elz 
Organization:
User Reference:  
Section:XSH 3/poll() 
Page Number:1399-1400 
Line Number:46800-1. 46807-46813, 46820, 46824, 46867 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1448#c5386 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2021-02-02 22:12 UTC
Last Modified:  2021-07-02 10:58 UTC
== 
Summary:Misleading text in description of poll()
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2021-02-02 22:12 kreNew Issue
2021-02-02 22:12 kreName  => Robert Elz  
2021-02-02 22:12 kreSection   => XSH 3/poll()
2021-02-02 22:12 krePage Number   => 1399-1400   
2021-02-02 22:12 kreLine Number   => 46800-1.
46807-46813, 46820, 46824, 46867
2021-06-18 14:08 geoffclare Note Added: 0005386  
2021-06-24 15:29 geoffclare Note Edited: 0005386 
2021-06-24 15:30 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1448#c5386
2021-06-24 15:30 geoffclare Status   New => Resolved 
2021-06-24 15:30 geoffclare Resolution   Open => Accepted As
Marked
2021-06-24 15:31 geoffclare Tag Attached: issue8 
2021-07-02 10:58 geoffclare Status   Resolved => Applied 
==

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

[shwaresyst via austin-group-l at The Open Group]

To the extent XBD 11.1, #6 applies and 2's complement notation is the internal 
representation required, the standard is pretty clear. The first 3 cases all 
evaluate to numeric 0, whether specified in paired quotes or not since the 
shell does quote removal, the +0 case is always a string since + is disallowed 
as a sign character. For the -0 case, since 2's complement does not have a 
representation for it, the practice is it is treated as equivalent to 0. XBD 
11.1 permits leading zeroes, including on a 0 value, for the 00 case, since the 
interpretation is always as decimal. For $'\0' this is effectively a zero 
length string, not a number, even if 2 NUL chars get stored as the 
argument..Similar to +0 is $'\r0',  is not a permitted sign char so that's 
a string. 
Now if more implementations than not are treating a single argument that might 
be a number as an implied "= 0" test, despite it being pretty clear the 
argument chars in this case have to be considered a string, then perhaps the 
Exit Status needs to reflect that as the predominant practice.
 
  On Fri, Jul 2, 2021 at 4:31 AM, Geoff Clare via austin-group-l at The Open 
Group wrote:   Stephane Chazelas wrote, on 01 Jul 
2021:
>
> BTW, for "expr", what is "zero" meant to be?
> 
> I see some variation in behaviour for "00", " 0", "-0", "+0",
> $'\r0', which some (but not all) also treat as zero.

> Also 0,000 or 0,000,000 in locales where "," is a thousand
> separator with ast-open expr (also the builtin expr of ksh93 if
> built as part of ast-open).

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.
However, that would require "expr 0" to exit with status 0 (because
the 0 argument is treated as a string in this case), which does not
match existing practice.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

  

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

[Vincent Lefevre via austin-group-l at The Open Group]

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.
> However, that would require "expr 0" to exit with status 0 (because
> the 0 argument is treated as a string in this case), which does not
> match existing practice.

And what about "-0"?

With expr from GNU coreutils 8.32 under Debian, I get:

$ expr 0 ; echo $?
0
1
$ expr -0 ; echo $?
-0
1
$ expr "" \| -0 ; echo $?
0
1
$ expr "" \| 01 ; echo $?
01
0

Note that for the 3rd result, I would expect -0 instead of 0 to be
consistent with the 2nd and 4th results.

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 "" \| 01 ; echo $?
01
0

For -0 (2nd and 3rd results), the exit status 0 does not seem to be
consistent with the exit status 1 of the 1st result.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Stephane Chazelas via austin-group-l at The Open Group]

2021-07-02 10:08:52 +0100, Stephane Chazelas via austin-group-l at The Open 
Group:
[...]
> It's a common problem in practice
[...]

expr has so many design flaws, maybe the best approach would be
to remove it from the standard altogether.

In practice, it can't be used reliably, and it's mostly
redundant with awk (we'd need gawk's match() 3rd argument
handling and back-reference support in ERE to get the equivalent
of the ":" operator though).

-- 
Stephane

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

[Stephane Chazelas via austin-group-l at The Open Group]

2021-07-02 09:31:11 +0100, Geoff Clare via austin-group-l at The Open Group:
> Stephane Chazelas wrote, on 01 Jul 2021:
> >
> > BTW, for "expr", what is "zero" meant to be?
> > 
> > I see some variation in behaviour for "00", " 0", "-0", "+0",
> > $'\r0', which some (but not all) also treat as zero.
> 
> > Also 0,000 or 0,000,000 in locales where "," is a thousand
> > separator with ast-open expr (also the builtin expr of ksh93 if
> > built as part of ast-open).
> 
> 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.
> However, that would require "expr 0" to exit with status 0 (because
> the 0 argument is treated as a string in this case), which does not
> match existing practice.
[...]

On Solaris, expr 0 returns false, but all of 00, -0... return
true.

Note that it also affects the boolean operators & and |

expr 00 '|' 1

give 00 or 1 depending on the implementation.

On Solaris, 00 is true there even though 00 is considered as 0
when used as an arithmetic operand (such as expr 00 + 1).

It's a common problem in practice when you use errexit and the :
operator as in:

value=$(expr "x$string" : 'x.*"\(.*\)"')

Which returns false when what is matched is the empty string or
a string that looks like zero (with variations between
implementation (and with the locale with some) as to what looks
like zero).

See also:

value=$(
  expr "x$string" : 'x.*"\(.*\)"' '|' \
   "x$string" : "x.*'\(.*\)'
)

-- 
Stephane

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

[Geoff Clare via austin-group-l at The Open Group]

Stephane Chazelas wrote, on 01 Jul 2021:
>
> BTW, for "expr", what is "zero" meant to be?
> 
> I see some variation in behaviour for "00", " 0", "-0", "+0",
> $'\r0', which some (but not all) also treat as zero.

> Also 0,000 or 0,000,000 in locales where "," is a thousand
> separator with ast-open expr (also the builtin expr of ksh93 if
> built as part of ast-open).

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.
However, that would require "expr 0" to exit with status 0 (because
the 0 argument is treated as a string in this case), which does not
match existing practice.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England