Paul Eggert wrote: > On 09/05/2012 07:51 AM, Linda A. Walsh wrote: > >>> Just start the script with "#!/bin/sh", as usual. >>> When invoked that way, Bash and other shells are POSIX-compliant >>> in this area. >>> >> To what level of posix... >> > To all the levels that are relevant for this discussion. > > In practice, people use "#!/bin/sh" and it works pretty well > to avoid compatibility issues like this. It's not perfect > for all POSIX issues, but you were asking for a solution to > a particular problem, and this should solve your problem. > ----- Now I remember how I got here in the first place... It was because of bash moving to the POSIX 2003 standard and breaking many things I'd come to rely on, that I eventually realized that it was unsuitable to rely on for programming. I had written a logical volume snapshot generator and manager in about ~1500 lines of shell script across multiple files -- mostly as a proof of concept -- but also because it seemed simple and grew as I realized it was 90% error condition handling. Bash got very unreliable in handling error conditions via "-e" w/the new POSIX standard -- can't return non zero from a function (so no more mathematical functions), can't return non-zero from a calc (()) or let statement -- both of which now trigger error exits under "-e" due to POSIX More stuff happened, I decided to throw it away and rewrite in perl. I'm still wanting to call rm -fr without wild cards to remove everything in a directory. One would think the "rm" utility which is *designed* to remove files recursively, would do the task and NOT need the shell to do it's job. My perl program has tried to call rm -fr . and *, neither of which work. if rm can't remove all the files in a dir by itself -- I assert it is failing it's job as an 'rm' program. Removing files is it's sole job in life... it can remove singles and directories... using rm -fr ./. or dir/. or . were all ways of removing all contents under their targets without removing the directory. That feature is now gone. So I'd like to request it be added when not operating under POSIX_CORRECTLY. It's the right thing to do for the command line. We don't have so many clueless dweebs in a tty window -- most want point and click. I know I don't want to call bash as a helper for rm -- as I know with BASH_ENV, and such, it can very easily be running alot of overhead code besides the simple rm function I wanted to do. I think on many systems /bin/sh is a link to ash or dash, and no telling how they will act/perform -- I don't want an extra dependency. So should I start looking to write a patch for rm and possibly fork it? Just realizing that I'm where I'm at today because of bash going POSIX has left me pretty cold.