April Chin wrote: > Roland Maint wrote: > > bugmail-sender at Sun.COM wrote: > > > > > > *Synopsis*: *ksh93* unset of a variable which is not set should return 0 > > > > > > > > > *Change Request ID*: 6791838 > > > > > > *Synopsis*: *ksh93* unset of a variable which is not set should return 0 > > > > > > Product: solaris > > > Category: shell > > > Subcategory: korn93 > > > Type: Defect > > > Subtype: Functionality > > > Status: 5-Cause Known > > > Substatus: > > > Priority: 3-Medium > > > Introduced In Release: > > > Introduced In Build: > > > Responsible Engineer: <User 1-5Q-5151> > > > Keywords: > > > > > > === *Description* > ============================================================ > > > In ksh93, the special builtin "unset" will exit 1 when its argument is a > > > variable which is not set, but it should exit 0, according to the POSIX > standards. > > > > Erm... I interpret the standard a bit different in this case: > > http://www.opengroup.org/onlinepubs/000095399/utilities/unset.html says: > > -- snip -- > > EXIT STATUS > > > > 0 > > All name operands were successfully unset. > > >0 > > At least one name could not be unset. > > -- snip -- > > > > Both ksh88, ksh93 and /usr/xpg4/bin/sh in Solaris behave like this: > > -- snip -- > > $ /usr/xpg4/bin/sh -c 'unset kjashdjkashd || print "unset returned > > non-zero exit code"' > > unset returned non-zero exit code > > $ ksh -c 'unset kjashdjkashd || print "unset returned non-zero exit > > code"' > > unset returned non-zero exit code > > $ ksh93 -c 'unset kjashdjkashd || print "unset returned non-zero exit > > code"' > > unset returned non-zero exit code > > -- snip -- > > > > Don: Is there any clarification request which defined the behaviour of > > "unset" more precisely ? > > I did confirm this interpretation with Don Cragun, and he agrees. > ksh93 (and the Solaris standard shell /usr/xpg4/bin/sh) would need to return 0 > in the case of unsetting a variable which is not set, to > conform with the standard. > > I guess you could also interpret the > > 0 exit value for "at least one name could not be unset" > to not be true in this case. The name was unset already, so the result > is still that the name is unset. Therefore, unset was successful.
Ok... ... right now ksh93 prints the following output for the following two testcases: -- snip -- $ ksh93 -c 'unset kjashdjkashd ; print $? ; unset kjashdjkashd ; print $?' 1 1 $ ksh93 -c 'kjashdjkashd="abc" ; unset kjashdjkashd ; print $? ; unset kjashdjkashd ; print $?' 0 0 -- snip -- What is the expected output in both cases ? Does this change mean the shell will have to track variable names even if they were "unset" (until now I always interpreted $ unset varname # as a variable/shell equivalent to "rm", e.g. once the variable is "unset" it is really gone and no traces are left) or that "unset" just returns "0" in all cases above ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
