Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14048 > unrolled thread
| Started by | Martijn Dekker <martijn@inlv.org> |
|---|---|
| First post | 2018-04-14 05:29 +0200 |
| Last post | 2018-04-14 05:29 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return' Martijn Dekker <martijn@inlv.org> - 2018-04-14 05:29 +0200
| From | Martijn Dekker <martijn@inlv.org> |
|---|---|
| Date | 2018-04-14 05:29 +0200 |
| Subject | Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return' |
| Message-ID | <mailman.12345.1523676564.27995.bug-bash@gnu.org> |
Op 14-04-18 om 03:49 schreef Chet Ramey: > On 4/10/18 5:56 AM, Martijn Dekker wrote: >> It seems odd that the RETURN trap would be triggered while a RETURN trap >> action is still being executed. Might it be better to temporarily >> deactivate the effect of '-o functrace' while a RETURN trap action is being >> executed? > > Well, trap handlers are recursive, in the sense that you can execute a trap > on signal X from a signal X trap handler. I'm not sure how that would happen. Isn't a signal blocked while executing its trap handler? > If the RETURN trap is inherited > by functions, and traps are recursive, wouldn't the bash behavior be the > logical thing to do? I suppose. But if a signal is blocked while executing the respective trap, perhaps it would also be logical to deactivate the RETURN pseudosignal while executing a RETURN trap. It seems like this is already done for the ERR pseudosignal, as "trap false ERR; false" does not cause an infinite loop. - M.
Back to top | Article view | gnu.bash.bug
csiph-web