Ah, I know what's happening. Let's take out the exits: $ ksh -c 'trap "echo INT" INT; trap "echo ERR" ERR; sleep 10' ERR INT
$ bash -c 'trap "echo INT" INT; trap "echo ERR" ERR; sleep 10' INT ERR So BOTH traps are being processed, just the order is different. So, perhaps you should also use an EXIT trap: $ ksh -c 'trap "echo INT" INT; trap "echo ERR" ERR; trap "echo EXIT" EXIT; sleep 10' ERR INT EXIT You can set flags in the other traps, and then do an additional exit 8 or exit 9 from the EXIT trap to get your desired exit value. On 28 April 2017 at 21:18, Danny Weldon <danny.wel...@gmail.com> wrote: > I'm guessing that ksh is prioritising internal traps (ERR, KEYBD, DEBUG) > higher. > > Both of these print ERR when interrupted: > > ksh -c 'trap "echo ERR; exit 1" ERR; trap "echo INT; exit 2" INT; sleep 10' > ksh -c 'trap "echo ERR; exit 1" ERR; trap "echo INT; exit 2" INT; /bin/sleep > 10' > > Whereas both of these print INT when interrupted: > > ksh -c 'trap "echo INT; exit 2" INT; sleep 10' > ksh -c 'trap "echo INT; exit 2" INT; /bin/sleep 10' > > Not sure if this should be called a bug or just a difference in logic. > However, > maybe ksh should switch to how bash and zsh are doing it anyway. > > On 28 April 2017 at 10:24, Janis Papanagnou > <janis_papanag...@hotmail.com> wrote: >> Are you implying that it's not possible to catch a terminal signal >> >> in ksh while you're inside a ksh built-in or in an external command >> >> because in ksh it's delivered as error and caught by the ERR trap? >> >> How sensible is that? - As said, bash and zsh behave more sensibly. >> >> So are you saying that the observed behaviour is no bug in ksh but >> >> works as designed? - I'd be curious about a rationale for that. >> >> >> Thanks. >> >> >> Janis >> >> >> ________________________________ >> Von: Bruce Lilly <bruce.li...@gmail.com> >> Gesendet: Freitag, 28. April 2017 01:44 >> An: Janis Papanagnou >> Cc: ast-us...@research.att.com >> Betreff: Re: [ast-users] trap issue >> >> Your example used sleep, which in some cases is a built-in and >> in other cases is an external program. >> >> For testing purposes, you might want to try something different, >> e.g. a select statement which will wait for input, and which you >> can interrupt: >> >> TMOUT=10 >> PS3="" >> select foo in "" >> do : >> done >> >> [note that this doesn't do anything useful, and will loop until >> it times out if not terminated by a signal or EOF followed by >> return] >> >> That should run your interrupt trap when interrupted from the >> terminal. And you could send a signal explicitly (e.g. from >> another shell) and that also should trigger your traps. >> >> Note that select is a keyword -- it is processed directly by >> ksh -- as opposed to built-in functions and external programs. >> >> _______________________________________________ >> ast-users mailing list >> ast-users@lists.research.att.com >> http://lists.research.att.com/mailman/listinfo/ast-users >> > > > > -- > Regards > > Danny -- Regards Danny _______________________________________________ ast-users mailing list ast-users@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-users
