Kemp.Catwalk@dockmaster.arpa (12/25/88)
> [[ . . . 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@dockmaster.arpa)