find

[Kemp.Catwalk at dockmaster.arpa]

> [[ . . . So reread the manual page and then try
> "find . -name filename -print".     . . . Oh, and by the way,
> the syntax to do this under VMS is MUCH uglier. --wnl ]]

Bill,
    You didn't put a smiley after that last crack, so here goes:

The VMS syntax is, of course:
$ dir [...]filename

This raises the issue of where filename expansion should take place.  I
can think of three problems with having filename expansion done by the
shell:

1) It imposes an arbitrary limit on the number of files a command can
operate on.  This isn't too bad because as disks and memory get larger
people can keep hacking the shell to raise the limit, but it is
philosophically troublesome to have any such arbitrary restriction.

2) It causes the shell to expand the whole mess before doing *any* real
work, causing delays when there are a large number of files. I would like
instant response when I type 'more *.c'.  Again, this isn't much of a
problem in practice.

3) The REAL problem: it destroys the basic semantic difference between
command line arguments and files.  The unix approach of having the shell
do the expansion (of a command with no options, for simplicity):

     for (i=1; i<argc; i++)
         process(argv[i]);

is contrasted to the VMS approach of having the program control filename
expansion:

     for (i=1, i<argc; i++) {
         n = 0;
         while (expand_filespec(argv[i], &n, filename))
             process(filename); }

(The actual VMS routine is LIB$somethingorother, I've forgotten what; n is
an opaque state variable to keep track of where you are.)

This avoids entirely the problem of files with funny names, and it allows
programmers to be more intelligent about how to respond to user input.
For example, rm *.o could just do it without asking, but rm * .o could ask
'Are you sure?'.  The 'time honored hack' of creating a file called -i to
protect a directory is obscene; i.e. it is obscene that a file can be
interpreted as a command line option.

[[ It doesn't completely avoid the problem of files with funny names.  A
naive user will still have problems removing a file called "-", for
example.  I suppose it would open the possibility of using "rm -i *".
--wnl ]]

Of course none of this necessarily relates to the question of find's
syntax vs dir, but the fact is that the VMS filename expansion routine
currently does directory expansion as well, and that present shells (at
least sh and csh) do not.  This means that each command that wants to
traverse directories has to have special code to do it, and probably a
special option (-r) to enable it.  Now that's a kludge.

[[ There is nothing preventing the incorporation of a recursive syntax in
a shell, except perhaps for total number of arguments.  The big difference
is that with the expansion in the shell, one just needs to use that shell;
but with the expansion in each program, at the very least one needs to
change a shared library and at the worst one needs to relink everything.
Several times I have intentionally typed "mv file*", knowing that I had a
"file" and a "file~" and nothing else, and was comfortable in the
knowledge that it would do what I wanted.  On the other hand, I have also
occasionally typed "mv file*" when I meant "mv file* .." and been upset at
the results.  No matter what, I always want the ability to type
"mv verylongfilename{,~}"  I can't do that in VMS and it would be hard to
make that work in VMS's "expand in the program" paradigm.  --wnl ]]

The biggest surprise I found when migrating from VMS to un*x was that a
system with such an emphasis on compiler technology (lex, yacc, etc) and
'little languages' (pic, tbl, etc) could have such a crummy user
interface.  Getopt is dirt compared to VMS' cdl (command definition
language) scheme.

[[ OH DEFINITELY!  I would much rather redirect output from a program with
    $ set sys$output filename.lis
    $ run program
    $ set sys$output
That is so much easier in my mind than that horrible and verbose syntax
that the Un*x shells impose on people.  Imagine:  using less than and
greater than signs!  :-)
In all seriousness:  each user interface has its good points and its bad
points.  And people will argue them religiously until the end of time.
--wnl ]]

This really belongs in the unix-flames list, but I guess sun-spots is
close enough :-).

[[ And I think this will be enough for now.  The last thing I want to see
is another Unix vs. VMS war.  There are much more appropriate lists on
which this argument can take place.  --wnl ]]

   Dave Kemp       (Kemp at dockmaster.arpa)