Chris Pickett writes: > > AFAIK it's more likely that you build ksh93 the normal way and not with > > the adjusted builtin table which changes the builtin command bindings to > > match PSARC 2006/550. If the list of default builtins is not adjusted > > you may get a couple of weired effects (the same issue+bug in "uname" > > builtin hit Blastwave's "pkg-get" badly) ... > > 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. Thanks for the information; I'll update the bug. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
