On Mon, Jul 2, 2012 at 9:16 PM, David Korn <[email protected]> wrote:
> cc: [email protected] > Subject: Re: [ast-users] [ksh93] How to return $? from a function when $? > > 256 > -------- > > > For example, following code is very common in scripts: > > > > ### CODE BEGIN ### > > function debug > > { > > return > > } > > > > function runcmd > > { > > typeset cmd=$1 > > typeset rc > > > > debug "+++ $cmd" > > eval "$cmd" > > rc=$? > > if (( rc )); then > > debug "+++ $cmd failed with $rc" > > else > > debug "+++ $cmd succeeded" > > fi > > > > return $rc > > } > > > > runcmd '/usr/bin/sleep 15' > > echo $? > > ### CODE END ### > > > > The problem is when the command is killed by a signal, we cannot return > the > > correct $? (> 256) from the runcmd() function. Bash does not has this > > problem since $? is equal to 128+signal when a command is killed. > > > > (attachment 1 18/1063 text/html "1.att") > > > > This is a bug that is already on my list for ksh93v. > > The problem with using exit codes of 128+signo (as the Bourne shell did), > is that users can use these exit normal codes. For historical reasons the > standard allows 128+signo, bug 256+signo is safer. > > User who do 'exit 267' must get 11 since only the lower eight bits > are valid. > > However, the shell should treat exit $? specially since it means > I don't think it's enough to only treat $? (for both exit and return) specially. Like in my example, it's very common to save $? in a tmp var and then return (or exit) it later. > propogate an exit code. For a program it means exit with > this signal by sending the signal to the current process. > > For a function, it has to preserve the 256. The key is to > differentiate > exit 267 > and > exit $? > > The former will become ($?&0xff) the latter, $?. > > David Korn > [email protected] >
_______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
