Scott Rotondo <[email protected]> writes: > [email protected] 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$ >> > > Casper has mentioned this a couple of times on this alias, and I agree > that the example above doesn't behave the way I would want or expect. > > Now I'm curious: Is there a faction out there arguing that the current > bash behavior is correct and shouldn't be changed? Does someone > actually rely on the current behavior?
If you were thinking it might be me, since I asked for examples... no. As I mentioned I'm not knowledgeable enough really to have an opinion. I can say that in the 100 plus or so bash scripts I've written, it never came up as a problem, but then my scripts are pretty primitive. Also, I switched to ksh93 some yrs ago for most scripting, just for the `=~' (awk like) operator... but Bash has had that for a while now too. In fact I find many of my ksh/bash scripts are largely interchangeable. Trouble occurs with my old scripts if it uses arrays since I liked ksh93: set -A somearrry $(find /path -name 'somewonkyname') syntax. Just seemed obvious and easy to write. Whereas bash needs: somearr=( $(find /path -name 'somewonkyname') ) Ksh can read that too but I still like the `set -A' syntax. All and all not a very significant problem at my low level. _______________________________________________ opensolaris-discuss mailing list [email protected]
