John Stalker:
> For what it's worth, I agree that it's a problem.
hooray! thanks :)
> Does it need fixing? Implementing it properly would break most shell scripts
> I've written.
Well, I have a fix that should not break any real scripts, I repeat it below.
Russ Cox:
> to the original poster: there's definitely a logical consistency to your
> original proposal. others have pointed out specific flaws, but the
> fundamental issue is that it's just not the same system anymore.
Thanks. I've already shown how to fix the problem by adding a meaning to `--':
if `--' is seen, do not do anything dwimmy in the case of 0 or 1 files in the
list, treat them like any longer list. The system is very much the same.
My solution fixes the problem and I claim it would not break any existing real
shell scripts, or upset interactive use, however it would remove many bugs.
Now, about the globbing...
erik:
> if we follow your redesign of unix, we would never get an error because
> cat * does nothing and wouldn't be an error at all.
"redesign of unix" is overstating it.
There should not be an error when a glob or pattern matches nothing.
"none" is a perfectly valid reply to the query *.c - what .c files are here?
For interactive use, an environment variable WARNIFEMPTY or something could
request warnings (or ERRORIFEMPTY for errors) from the shell if a glob expands
to nothing; or from commands if a command is run with no files to operate on.
Or perhaps we could have a different globber that does the right thing,
such as `{glob *} - that would be okay for scripts, and the status quo is
tolerable for interactive use.
Maybe the regular globbing can't be fixed without breaking stuff - but I don't
know of any program that does depend on this bogus misfeature, and I'm sure I
could find plenty of scripts that break because of it... and it's no good to
blame the writers of those scripts, it is a clear fault in the system.
I don't admire the various god-awful hacks proposed to avoid pitfalls stemming
these bugs.
Sam
