casper@sun.com wrote:
> Bash doesn't handle signals properly in interactive shells.
Bash also does not handle signlals properly in non-interactive shells.
If you call bash -c cmd, bash sets up process grous and thus you cannot
simply abort layered "make" calls by typing ^C. My "smake" f
>No, I wasn't expecting a response from any particular person. I was just
>honestly wondering if this is a controversial point. If not, I'm a
>little surprised that no one has modified bash to behave more like other
>shells in this respect.
Bash doesn't handle signals properly in interactive
Harry Putnam wrote:
Scott Rotondo writes:
casper@sun.com wrote:
The most broken part of bash is its signal handling:
cd /net/somehost/file/dir ; rm -rf *
"somehost" hangs; now you type a ^C to interrupt the "cd".
What happens?
bash-3.2$ sleep 10; echo foo
^C
foo
bash-3.2$
Scott Rotondo writes:
> casper@sun.com wrote:
>> The most broken part of bash is its signal handling:
>>
>>
>>
>> cd /net/somehost/file/dir ; rm -rf *
>>
>> "somehost" hangs; now you type a ^C to interrupt the "cd".
>>
>> What happens?
>>
>> bash-3.2$ sleep 10; echo foo
>> ^C
>> foo
>>
casper@sun.com wrote:
The most broken part of bash is its signal handling:
cd /net/somehost/file/dir ; rm -rf *
"somehost" hangs; now you type a ^C to interrupt the "cd".
What happens?
bash-3.2$ sleep 10; echo foo
^C
foo
bash-3.2$
Any other shell:
$ sleep 10; echo foo
^C$
