According to Jon Stanley on 1/26/2010 7:05 PM:
On Tue, Jan 26, 2010 at 8:57 PM, Michael Webb <address@hidden> wrote:
I'm running /bin/csh. Don't know how to figure out the coreutil version,
however the rm man-page says 5.2.1.
Wow, that's old. The latest stable version is 8.4, and includes several
fixes for rm (although I think we've already established that this was
your shell, and not rm).
Yeah, like Eric said, I think that this is a csh problem rather than a
coreutils problem. I would even think that csh is behaving wrongly
here - rather than refusing to run rm because the glob didn't match,
it should pass the f* straight through to rm to deal with as it
pleases, unless you explicitly told the shell to fail (as Eric did in
his example). I don't have any standards to back that up though, Eric
is the POSIX-citing guy around here :)
csh is not specified by any standards. It's personal choice whether you
use it instead of sh (but personally, I _hate_ csh variants, because they
are so impossible to use for any decent scripting, and so woefully
under-specified).
My guess is that bash originally provided the failglob option to make it
easier for people switching from tcsh to bash to still keep the default
behavior of csh. 'man tcsh' states:
| It is an error for a glob‐pattern containing ‘*’, ‘?’, ‘[’ or ‘~’, with
| or without ‘^’, not to match any files.
It also looks like tcsh provides the nonomatch shell variable to make tcsh
take on the somewhat more POSIX-like behavior of passing unmatched globs
through.
Any standards for that Eric?
Bash's '-s failglob' is an extension allowed by POSIX, but as an
extension, it is not standardized. The moment you use an extension, then
the shell is within its right to use an alternate behavior (in this case,
failing when a glob doesn't expand, rather than calling the app with a
literal argument of "f*"). So I see nothing in the above example that
conflicts with the standards; although a strictly compliant app wouldn't
have been using either csh or failglob in the first place.