expr stripping off leading zeroes from a string

[Paul Maglinger]

Using the following:

#!/bin/sh
x='00545'
expr substr "$x" 1 2

The above code produces the following output:
54

Shouldn't it have produced:
00

Running HP-UX 11.23 on Itanium servers.

[OldSchool]

what does it do in ksh?

[Paul Maglinger]

Same thing. Tried it on several different shells, no joy.

[James R. Ferguson]

Hi:

This returns "00" on an 11.23 Itanium for me:

# cat ./mysh
#!/bin/sh
x='00545'
expr substr "$x" 1 2

# ./mysh
00

# what /bin/sh
/bin/sh:
Version M-11/16/88f
$ B.11.23 Aug 22 2007 09:08:12 $
builtin.c $Date: 2005/01/19 00:36:04 $Revision: r11.23/5 PATCH_11.23 (PHCO_32444)
service.c $Date: 2007/03/06 17:54:39 $Revision: r11.23/3 PATCH_11.23 (PHCO_34129)
xec.c $Date: 2005/11/22 04:08:50 $Revision: r11.23/6 PATCH_11.23 (PHCO_34129)
emacs.c $Date: 2007/01/05 12:12:17 $Revision: r11.23/4 PATCH_11.23 (PHCO_34129)
fault.c $Date: 2007/03/06 17:54:43 $Revision: r11.23/6 PATCH_11.23 (PHCO_34129)
history.c $Date: 2007/04/23 15:02:12 $Revision: r11.23/1 PATCH_11.23 (PHCO_36506)
io.c $Date: 2007/04/23 15:02:21 $Revision: r11.23/4 PATCH_11.23 (PHCO_36506)
jobs.c $Date: 2005/08/10 00:06:06 $Revision: r11.23/5 PATCH_11.23 (PHCO_32444)
test.c $Date: 2007/10/12 18:33:56 $Revision: r11.23/2 PATCH_11.23 (PHCO_36506)
$Revision: @(#) ksh R11.23_BL2007_1114_1 PATCH_11.23 PHCO_36506


Regards!

...JRF...

[Paul Maglinger]

We've found some additional information.
This seems to occur when we have UNIX95=XP64 in the environment. When we unset this, it works correctly. Now I'm wondering why it doesn't work when UNIX95=XP64.

[James R. Ferguson]

Hi (again) Paul:

Using 11.23 (with current patches) on an rx2660, I can't reproduce this:

# cat ./mysh
#!/bin/sh
UNIX95=XP64
x='00545'
expr substr "$x" 1 2

...which works the same as :

# cat ./mysh
#!/bin/sh
UNIX95=
x='00545'
expr substr "$x" 1 2

...

I would never capriciously set 'UNIX95' unless you are specifically needing it; e.g with 'ps' to enable the '-o' formatting options.

Regards!

...JRF...

[Dennis Handly]

This also fails if you have "typeset -i x", since x would be an integer.

>This seems to occur when we have UNIX95=XP64 in the environment. When we unset this, it works correctly. Now I'm wondering why it doesn't work when UNIX95=XP64.

You shouldn't be exporting UNIX95=MAKE_EXPR_HAVE_DIFFERENT_SUBSTR_RESULTS.
The POSIX standard says using substr on numbers is unpredictable.

The only time you should use UNIX95 is with:
UNIX95=EXTENDED_PS ps -Hef ...
This only exports UNIX95 for the one command.

[James R. Ferguson]

Hi:

Do you have PHCO_36506 ? If not, you might try applying it (no reboot is required) and then retest.

Regards!

...JRF...

[Paul Maglinger]

Uh... just noticed a typo
We were exporting UNIX95=XPG4

Time for glasses...

[Dennis Handly]

>JRF: Do you have PHCO_36506?

Why would a shell patch break the correct standard behavior of expr(1), to make it work like Paul wants?

>just noticed a typo, We were exporting UNIX95=XPG4

No, you were really exporting: :-)
UNIX95=MAKE_EXPR_HAVE_DIFFERENT_SUBSTR_RESULTS

>Time for glasses

Or cut & past. :-)

[James R. Ferguson]

HI (again):

> Dennis: Why would a shell patch break the correct standard behavior of expr(1), to make it work like Paul wants?

A long shot, granted, but why not ask about the latest cumulative shell patch?

Regards!

...JRF...

[Dennis Handly]

>JRF: A long shot, granted

I suppose that make sense if you hadn't read my reply stating that expr(1) is working as mandated by the POSIX Standard.

[Bill Hassell · Accepted solution]

UNIX95 will have unexpected results on a number of different commands and libraries. Unless you search through every man page, even the simplest form of defining UNIX95 will trigger unique behavior. That's why exporting, even defining the variable in the current shell is never recommended.

Instead, UNIX95 should be defined (appear on the right side of =) just for the process such as ps:

UNIX95= ps -eH

As far as I know, UNIX95 only has to be defined, null as the above example, or assigned any string to change behavior.

[Dennis Handly]

>Bill: Unless you search through every man page

Unfortunately that's not good enough. :-(
Only these are documented, not expr(1).
for i in /usr/share/man/man1.Z/*; do
zcat $i | fgrep -q UNIX95
if [ $? -eq 0 ]; then echo $(basename $i); fi
done

awk.1 cp.1 edit.1 ex.1 find.1 patch.1 pr.1 ps.1 vedit.1 vi.1 view.1
11.31:
admin.1 alias.1 asa.1 awk.1 bg.1 cal.1 cp.1 cu.1
date.1 edit.1 ex.1 fc.1 fg.1 jobs.1 make.1 nl.1
od.1 patch.1 ps.1 pwd.1 rsh.1 sed.1 sh-posix.1
sort.1 unalias.1 vedit.1 vi.1 view.1 wc.1 who.1 xd.1

[James R. Ferguson]

Hi (again):

> Dennis: I suppose that [would] make sense if you hadn't read my reply stating that expr(1) is working as mandated by the POSIX Standard.

Yes, for the record, I didn't see that in the ~ 4-minutes between my suggestion to fetch the cumulative sh-posix patch and your indication that "The POSIX standard says using substr on numbers is unpredictable".

That's good to know and it suggests that one has to look at the POSIX standards to be aware of this.

Paul's example is with a string, albeit that the string consists of digits. Does the standard distinguish between "strings", "integers" and "strings of numbers"?

Regards!

...JRF...

[Paul Maglinger]

Always a pleasure to start up a lively conversation. Your information was quite useful and I appreciate your comments.

Just a side note that I'm getting better information (and faster) from this forum than I'm getting from the HP software support that we're paying for.

Thanks guys!

[Dennis Handly]

>... than I'm getting from the HP software support that we're paying for.

Very indirectly that pays for me. :-)

>JRF: Does the standard distinguish between "strings", "integers" and "strings of numbers"?

The latter doesn't exist:
A string argument is an argument that cannot be identified as an integer argument

The source checks if numeric and strips leading zeros.

The "APPLICATION USAGE" gives you a hint how to solve the problem:
expr substr X"$x" 2 2