Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Robert A Duff wrote:
>> Of course, it's all ridiculous: hiding file names that start with
>> "." is a stupid idea.  Expanding wildcards on the command line and
>> then passing separate args as strings is a stupid idea.  This is one
>> of the (few) areas where Windows does it right, compared to Unix.
>> Sigh.
>
> Expanding wildcards on the command line centralises that feature, so
> the users don't have to worry about how the individual applications
> have decided to implement wildcard expansion.

Yes, that is an advantage of having the shell do it,
(although "centralized" is somewhat dubious.  It's centralized
in 'sh'.  And 'csh'.  And 'bash'.  And 'find'.  And dozens of others.)
However, there are so many disadvantages, that I think
this part of Unix is just plain broken:

Note that I said, "passing separate args as strings", and I think that's
the worst part of it.  Defining the semantics of a language in terms of
textual manipulations is a Bad Idea.  That's why C macros are evil.  And
why pretty much the entire 'sh' language is such a horror.  And all the
other Unix shells are just as bad.  This is why 'make' is such a mess.
In Ada, the semantics of "X, Y: array ...;" are defined in terms of
textual substition, which leads to various surprises.  At least this
design mistake doesn't permeate Ada.

Textual substition is a simple rule (just change "*.ada" to
"foo.ada bar.ada baz.ada", or whatever).  But it leads to
complicated and surprising consequences.

If I say, "cp *.ada backup", it means copy all the *.ada files
into the backup directory.  Suppose I accidentally hit <enter>
before typing "backup", so I say, "cp *.ada".  On a reasonable
system, I'd get an error -- one argument passed, but 'cp' is
expecting two.  On Unix, I usually get an error, but it's
something nonsensical, like "zoo.ada is not a directory".
And if it just so happens that there are exactly two files
matching *.ada, I get no error -- instead of backing up
my files, it destroys one of them!

Here's another stupidity:

% grep somethingorother *.ada
Arguments too long
% grep somethingorother `find some-directory -name '*.ada'`
Too many words from ``

The idea that all the file names have to be stored in memory during the
search is just plain broken.  What if I wanted to search all the files
on my huge disk?  (Side issue: Unix doesn't have a standard wildcard
that means "a certain directory, and all subdirectories underneath that
in the tree".  You have to use 'find' -- yuck.)  (Another side issue:
grep takes it arguments in backwards order, because of the way
wildcards work in Unix.)

Unix exacerbates this problem by using a fixed-size buffer for the
command line.  No matter how big it is, it is always both too big and
too small.

(Why is the "search" command called "grep"?  For that matter, why is the
"help" command called "man"?)

>...I would definitely not
> be happy with a system, where each and every program had a slightly
> different interpretation of a wildcard.

Agreed.

But it doesn't have to be that way.  On VMS, wildcards are treated in a
completely uniform manner.  The OS provides a service to iterate through
the files corresponding to a given wildcard, and all programs use it.
No problem.  Same is true on other OS'es I've used.

The problem you describe did exist on MS-DOS, and on Windows
(although I think it's not as bad as it used to be) -- which is
surprising, since DOS provided a similar service to VMS.
I admit that the Unix design prevents this problem.
But even if you insist on having the shell expand wildcards,
"cp *.ada backup" should pass exactly 2 arguments to 'cp' --
a list of file names, and a directory name.

> Given how anarchistic most "unix programmers" are, this is definitely
> a more user friendly solution.

Sigh.  No language/OS design can prevent incompetent programmers from
making a mess.  To me, it seems sufficient to have a (standard!) service
that says "Apply so-and-so procedure to each file (or file name) that
matches such-and-such wildcard."  I don't know why it worked well on
VMS, but not on MS-DOS.

Sorry for the mostly off-topic rant.  The Ada question is: to what
extent should Ada.Directories mimic all this foolishness?

- Bob