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.