2020-04-20 1:42 Robert Elz <k...@munnari.oz.au>:
> Probably not, bosh is derived from that shell (more or less) and it is
> also A
>
> [...]
>
> So are the FreeBSD and NetBSD shells (which is not surprising, as like
> dash, they're descendants of ash).
>
> You can also add zsh to A:
Thank you for the information. I have also tested ksh93, pdksh and
oksh (OpenBSD KornShell) on FreeBSD. `ksh93' is (B), and `pdksh' and
`oksh' do not implement the special treatment in trap handlers. Here
is the current list:
(A) zsh (zsh-5.7.1, zsh-5.6.2)
ash variants (dash-0.5.10.2, busybox-1.28.3, FreeBSD sh, NetBSD sh),
Bourne sh variants (heirloom-sh-050706-4, bosh-2020/04/18)
(B) bash-4.4, gwsh,
ksh variants (ksh-2020.0.0, ksh93.u_1, mksh-R57, mksh-R56)
(C) yash-2.49
(D) none
(Not Implemented) bash-4.3, pdksh-5.2.14.2, oksh-6.6.1, posh-0.13.2
I think now it is rather clear that the current wording of POSIX is
somehow ambiguous and there can be different interpretations. In
fact, there is a split, (A) vs (B), in shell implementations.
>> 2020-04-19 23:00 Harald van Dijk <a...@gigawatt.nl>:
>>> It does still mean that anyone writing a function needs to beware that
>>> exit and exit $? do not have the same effect, if there is any
>>> possibility that the function will be invoked from a trap action. I
>>> suspect most people writing functions will not be aware of that.
Yes, that is the problem. Actually, the original problem is that I
just want to perform `eval "$PROMPT_COMMAND"` in a trap action in Bash
script where `$PROMPT_COMMAND' is provided by users. If everything
is under the control, I can just always write `return $?', but the
commands in `$PROMPT_COMMAND' are specified by users who are unlikely
to care about this problem. This specific case is just my personal
one, but I think the behavior (B) can possibly cause similar problems
in other shell scripts in general.
>> 2020-04-19 20:51 Robert Elz <k...@munnari.oz.au>:
>>> [...]
>>>
>>> The end result, unless we can get agreement that some
>>> implementations are buggy, and will be fixed (which given the
>>> split seems an unlikely outcome) is likely to simply be that all
>>> of this simply becomes unspecified (or perhaps we could hope,
>>> implementation defined) which will mean even more cases where it
>>> becomes more difficult to write portable reliable code.
>>>
>>> kre
>> 2020-04-19 23:00 Harald van Dijk <a...@gigawatt.nl>:
>>> True, and if the intent is that exit and return behave differently
>>> and the standard is updated to clearly require that, I have no
>>> problem changing the shell back to the prior behaviour.
According to these comments, it seems like a deadlock. The standard
will not change until shells change their behavior to match with each
other, and shells will not change their behavior until the standard is
clarified. Actually I can understand both sides, but I think we can
find a point of compromise.
There are already different implementations so it is already difficult
to write portable and reliable code. Even some shells such as
`pdksh', `oksh' and `posh' do not implement the special behavior of
`return' in trap actions at all, so the standard does not describe the
current situation properly. Thus I think the side effect of making it
unspecified is limited. Maybe we can first let it be unspecified and
then wait to see whether the shells will switch the behavior from the
literal reading (B) to more sensible interpretation (A) or not.
- It might be difficult to change the behavior (B) of `ksh' and `mksh'
because its behavior is unchanged at least since 1993.
- While, `bash' implemented the behavior (B) in bash-4.4 which is
relatively recently in its long history, so maybe we can hope for a
change.
- Harald: The remaining shell with (B) in the list is `gwsh'. For
example, if the standard changes its description to `unspecified'
(instead of clearly requiring (A) or other interpretation), do you
think you have a chance to change the behavior back?
- I think `yash' with the interpretation (C) will follow the standard
anytime if the standard clarifies the intended behavior because
`yash' aims to strictly support POSIX.
Thank you.
--
Koichi
