Executing shell code on the signal stack, or why is this is a bad idea

Forwarding an interesting posting from Roland Mainz who did an investigation why signal trap processing in ksh93, bash and dash is currently not reliable. Lionel -- Forwarded message -- From: Roland Mainz Date: 3 June 2013 15:22 Subject: Re: [ast-developers] Realtime signal issue

Re: Executing shell code on the signal stack, or why is this is a bad idea

On 6 June 2013 11:29, Lionel Cons wrote: > Forwarding an interesting posting from Roland Mainz who did an > investigation why signal trap processing in ksh93, bash and dash is > currently not reliable. > > Lionel > PS: malloc() from AT&T libast, used by ksh93, is async signal safe. Unless bash's

bash: read: `0': not a valid identifier: check earlier

$ read 0 ddd bash: read: `0': not a valid identifier Can't the check be done earier? E.g.: $ read 0 bash: read: `0': not a valid identifier

Re: Executing shell code on the signal stack, or why is this is a bad idea

On 6/6/13 5:31 AM, Lionel Cons wrote: > On 6 June 2013 11:29, Lionel Cons wrote: >> Forwarding an interesting posting from Roland Mainz who did an >> investigation why signal trap processing in ksh93, bash and dash is >> currently not reliable. >> >> Lionel >> > > PS: malloc() from AT&T libast, u

typeset -p & manpage on it are confusing w/rt funcs

I wanted to test to see if a function was defined and looking at typeset in the bash man page, I see typeset ... The -p option will display the attributes and values of each name. When -p is used with name arguments, additional options are ignored. When -p is