2020-04-19 5:12 Chet Ramey <chet.ra...@case.edu>:
> The POSIX wording seems straightforward and implies (B). The `action'
> is a string that is defined to behave as if it were the argument to
> `eval', so it can be an arbitrary command, which makes (A) unlikely.
>
> You could always ask the austin-group list for an interpretation, or
> send me something that I could forward to the list for you.
Thank you for the suggestion. Is <austin-grou...@opengroup.org> the
mailing list you mentioned above? I have created an account in
opengroup.org and subscribed to the mailing list. I will later write a
question on wording of `return' special builtin in that list.
> That's an unreasonable statement, throwing out all uses of return without
> an argument because of how it behaves while running a trap.
OK. I agree that for the shell functions that will not be used in
trap handlers, no-argument `return' can be used without problems.
Actually the situation in my script (ble.sh) is a little bit special.
In my script, some parts of Bash features are emulated. I run `eval
-- "$PROMPT_COMMAND"' in SIGWINCH handler where `PROMPT_COMMAND' is
specified by users so is not under the control of the script but under
the control of the user. Naively, with interpretation (B), I need to put
restrictions on the commands that can be specified in
`PROMPT_COMMAND', on which there are no restrictions in the original
Bash. The use of no-argument `return' is common, and such
restrictions are non-trivial for users. In fact, there are already
existing Bash configurations, that use no-argument `return' in
`PROMPT_COMMAND', which I would like to support with my script. One
example is `bash-preexec' (https://github.com/rcaloras/bash-preexec)
which aims to provide a feature like `preexec' and `precmd' hooks of
zsh. `bash-preexec' uses no-argument `return'. The configuration
provided by iTerm2 for shell--terminal integration also uses this
`bash-preexec' framework.
I would appreciate it if you could provide me some suggestion on other
ways to work around the general problems caused by such user-provided
`PROMPT_COMMAND'?
2020-04-17 2:21 Koichi Murase <myoga.mur...@gmail.com>:
> Also, I have checked the behavior of other shells. `zsh', `ash'
> family (dash/ash, busybox sh) and `posh' does not implement the
> special treatment of `return' in trap handlers. `ksh' family
> (ksh93, mksh) and `yash' implements the interpretation (B). There
> is no existing implementation of (A). But currently I still think
> the intepretation (A) is reasonable. If there is rationale for the
> interpretation (B), I would like to know it.
Let me correct this paragraph. Actually `zsh', `dash' and `busybox'
implement the behavior of the interpretation (A). After my previous
email, I noticed that there was an oversight in testing the shells.
With the attached script `0015-test4.sh',
$ bash 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command preceding the trap action
$ bash-4.3 0015-test4.sh
In trap-argument: last command in the trap action
In a function call: last command in the trap action
$ zsh 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command in the trap action
$ dash 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command in the trap action
$ busybox sh 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command in the trap action
$ mksh 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command preceding the trap action
$ ksh 0015-test4.sh
In trap-argument: last command preceding the trap action
In a function call: last command preceding the trap action
$ yash 0015-test4.sh
In trap-argument: (failed to exit the function)
In a function call: last command preceding the trap action
$ posh 0015-test4.sh
In trap-argument: last command in the trap action
In a function call: last command in the trap action
which can be summarized in the following list:
Interpretation (A): zsh, dash, busybox
Interpretation (B): bash-5.0, ksh, mksh
Interpretation (B) [broken?]: yash
Not implemented: bash-4.3, posh
--
Koichi
#!/bin/bash
setexit() { return "$1"; }
invoke() { kill -USR1 $$; return 222; }
trap 'setexit 111; return' USR1
invoke
case $? in
(0) echo 'In trap-argument: last command preceding the trap action' ;;
(111) echo 'In trap-argument: last command in the trap action' ;;
(222) echo 'In trap-argument: (failed to exit the function)' ;;
(*) echo 'In trap-argument: (unexpected)' ;;
esac
stat=99
handler() { setexit 111; return; }
trap 'handler; stat=$?; return' USR1
invoke
case $stat in
(0) echo 'In a function call: last command preceding the trap action' ;;
(111) echo 'In a function call: last command in the trap action' ;;
(*) echo 'In a function call: (unexpected)' ;;
esac
