Date: Wed, 28 Oct 1998 18:55:53 +0100 From: Martin Cracauer <cracauer@cons.org> To: Brian Feldman <green@zone.syracuse.net>, Studded <Studded@gorean.org> Cc: =?iso-8859-1?Q?Dag-Erling_C=2E_Sm=F8rgrav?= <dag-erli@ifi.uio.no>, current@FreeBSD.ORG Subject: Re: sh and ~ expansion Message-ID: <19981028185553.A18168@cons.org> In-Reply-To: <Pine.BSF.4.05.9810250920150.18224-100000@zone.syracuse.net>; from Brian Feldman on Sun, Oct 25, 1998 at 09:21:20AM -0500 References: <362B74B6.B9B256B4@gorean.org> <Pine.BSF.4.05.9810250920150.18224-100000@zone.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.BSF.4.05.9810250920150.18224-100000@zone.syracuse.net>, Brian Feldman wrote: > Why don't we just use pdksh? It's even more compact than our current > Bourne/partially-Korn shell, and has lots of great Korn shell features > everyone loves but sh doesn't have. pdksh has a number of (IMHO) bugs with respect to signal handling. The problem here is "what happens when a sh child uses SIGINT and/or SIGQUIT intentionally, without using it as an indication that the user wants to exit?". I.e. emacs does this. In my opinion, and I'm going to prove it once I get through the Posix specs, the shell should abort a shell script only if a child exited with a signal exit status. In pdksh's opinion, a shell script is exited when a SIGINT was received while a child was running, no matter what the child does with it. Consider this script: #! /bin/sh emacs -nw /tmp/bla cp /tmp/bla ~/useful.txt emacs doesn't exit with signal status. If the user used C-g during his emacs session, pdksh will not execute the cp. If the user didn't hit C-g, pdksh will execute cp. Since C-g is a normal key in emacs and has nothing to do with exiting anything, this isn't useful behaviour. Our sh after the fixes BDE and me applied recently, will execute the cp in any case. The drawback of our behaviour is that chlients *must* exit with signal status on signals to abort the script. That means, if SIGINT or SIGQUIT is being chatched and the handler does some cleanup but will then exit instead of continuing the application, it has to kill itself. The FreeBSD build toolchain does this, but some ports fail, i.e. rsync. Nothingtheless our scheme is the only one that can truely support applications that use SIGINT and SIGQUIT for other purposes than exiting. Also, like bash pdksh fails to execute traps while a child that blocks signals is running. Consider this: #! /bin/sh trap 'echo aborting ; exit 1' 2 ./hardguy-that-blocks-sigint In bash and pdksh, the trap will be run *after* the blocking child exited, while in our sh it will run the trap immediatly. You strictly need this feature in system startup, where in /usr/local/etc/rc.d you will loose bedaly if you ever have a thing in startup that blocks signals, but hangs for some reason. You'll never get control back to the rest of the /etc/rc script if the shell executing it will execute traps only after the next child's exit. And I don't like that pdksh doesn't do . lib.sh if lib.sh is in the current directory, is not executable and '.' is not the $PATH. You have to use '. ./lib.sh' instead. I have to look up what Posix says, but this is counter-intuitive for me. For me, the file to read is not an executable, but something like a library, a config file, just a normal file and loading should follow file access rules ($PWD or absolute path), not executable loading rules ($PATH). I guess you will remark that this *is* in fact an exectable (at least potentially) and that an implicit '.' in whatever loading rules it follows causes the same problems as usual, so I hope POSIX is clear on the issue :-/ For me, using pdksh instead of ash is a primary reason why I thing that OpenBSD tends to solve problems with a big hammer too often. The same applies to pax vs. tar which has been exchanged before fixing the tar compatiblity mode. If you through away your shell and use a new one, you'll use a valuable resource: All the PRs collected over the years. For pdksh, you'll start from scratch, while the remaining problems in our sh are documented and me and Tor Egge (and BDE if something goes wrong) work on then from time to time. Maybe not enough, but I tend to say that volunteer situation is better than for many other parts of the system :-) For tests about proper sh and signal behaviour see http://www.freebsd.org/~cracauer/sh-sigint-testsuite/ Hope that helps. I don't think pdksh is a bad shell, but in my opinion FreeBSD is better served with ash for now. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981028185553.A18168>