Jonny dixit:

>following code:
> #!/bin/sh
> trap 'echo 0' EXIT
> unset v
> ${v?}
>
>bash and dash will run the "echo 0", mksh does not perform.
>Is this the intended behavior?

Hrm.

POSIX says:
   ${parameter:?[word]}
          Indicate Error if Null or Unset. If parameter is unset or
          null, the expansion of word (or a message indicating it is
          unset if word is omitted) shall be written to standard error
          and the shell exits with a non-zero exit status. Otherwise,
          the value of parameter shall be substituted. An interactive
          shell need not exit.

Also, the trap command description is not explicit about that here.
So it may actually be deliberate, but I do not know.

I’ve used the following test script:

trap 'echo EXtrap' EXIT
trap 'echo ERtrap' ERR
set -e
print -r -- "and run $1"
eval $1
echo and out

AT&T ksh runs the ERR trap, then the EXIT trap,
both when called with 'false' and '${v?}' as $1
argument.

mksh until R29g inclusive runs the ERR trap, then
the EXIT trap, when passed 'false'; mksh R30 and up
runs the ERR trap twice (bug?) then the EXIT trap.

For '${v?}', R21 was the last one to run the EXIT
trap; the ERR trap was never run.


This is neither documented nor specified somewhere.

I believe running the ERR trap once, then the EXIT
trap, may be the desired behaviour though, so I’ll
keep this open as a bug. It will most likely be fixed
in mksh R41b, if I can figure out a fix that is ;-)
as it may be tricky. If you want to get it fixed in
wheezy, please take it up with the release team yourself
once I’ve got a fix, which I’ll announce here.

Thanks for the discovery,
//mirabilos
-- 
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
     ⎜    System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;)       08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to