James Carlson wrote:
> Chris Pickett writes:
[snip]
> > I ran a diff over the log files, it looks that the 'set' builtin
> > behaves differently (old log is Bourne shell, new log is ksh93):
> > + /usr/sbin/route -n add default -gateway 192.168.0.1
> > + set -- add net default: gateway 192.168.0.1: entry exists
> > -+ [ 17 -ne 0 -a x192.168.0.1: = x192.168.0.1: ]
> > -do_delete=no
> > -+ [ -n 192.168.0.1 -a no = yes ]
> > -+ [ != true ]
> > ++ [ 0 -ne 0 -a x192.168.0.1: = x192.168.0.1: ]
> > ++ [ -n 192.168.0.1 -a yes = yes ]
> > ++ /usr/sbin/route -n delete default -gateway 192.168.0.1
> > ++ 1> /dev/null
> > ++ [ '' != true ]
> > + [ -z 192.168.0.1 ]
> >
> > The sh manual page is ambiguous which return code is expected for
> > 'set'. Is there any other documentation for sh?
>
> Looking at the code, it seems pretty clear that the author expects
> that 'set' doesn't change the return code value, and that the "-ne 0"
> is checking for failures out of /usr/sbin/route itself.
>
> It sure looks like this expectation is nonsense:
>
> /sbin/sh
> $ set -- /bin/false
> $ echo $?
> 0
> $ /bin/false
> $ echo $?
> 255
> $ set -- a b c
> $ echo $?
> 0
> $
>
> So, "set" happens to return 0 all the time in Bourne shell, and the
> code as written apparently doesn't do what was intended.
Erm... that is AFAIK wrong.
The Bourne shell returns a non-zero value (|17|) in Chris's example
above while ksh93 (note the quotes ("''") around empty variables - only
ksh93 does that for xtrace) returns |0| as required by POSIX (see
http://www.opengroup.org/onlinepubs/009695399/utilities/set.html).
I can reproduce the problem on my side (after some fighting with
VMware), patch follows in a few mins...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
