April Chin wrote: > > Date: Fri, 09 Jan 2009 23:58:02 +0100 > > From: Roland Mainz <roland.mainz at nrubsig.org> [snip] > > > 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 ? > > In both cases, unset should return 0. If it doesn't do it now, I don't > think that any tracking is needed for unset variables.
Ok... do you know if there is a clarification request which covers this change ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
