Re: win32 recursive glob broken

[Eli Zaretskii]

> Date: Sat, 24 Jan 2004 12:15:51 -0700
> From: address@hidden (Bob Proulx)
> 
> > If so, it seems counter to the traditional meaning of a recursive option
> > on  a command line utility.
> 
> Traditional for the UNIX operating system where grep originated?  Or
> traditional command behavior for the DOS platform?

FWIW, I'm not aware of any DOS-based ``traditional'' Grep program that
works like this.  But I don't pretend to know all of them, so maybe
there is such a beast somewhere.  In any case, it certainly isn't
``traditional'' for DOS programs to have such a universally recursive
behavior.

> (DOS is a platform without a doubt.  But I hesitate to it an
> operating system.)

You shouldn't, IMHO, not nowadays.  With all the add-ons on top of the
DOS kernel, like extenders and DPMI servers, and with all the ports of
Free Software, like Bash, Emacs, and TeX, it's possible to run
industry-strength applications, including most of GNU software, on a
bare-bones DOS machine.

> > I would expect the command to search all files matching the '*.c'
> > filespec in the cwd, AS WELL AS all files matching '*.c' in the the
> > entire directory hierarchy beneath the cwd. This seems obvious to me.
> 
> That is not obvious to me and that is not what I would expect.  I
> expect the file glob *.c to be expanded by the shell into a list of
> literal file names and handed to the command as arguments.  This
> provides a uniform wildcard interface for all commands.  Commands do
> not need to include wildcard processing code because the shell does it
> for all commands uniformly.

That's a bit idealistic: there's more than a single shell variety out
there, and they all differ in small ways as to the way they handle
wildcards, like when there's no match at all.

The modularity issue is another weak point: in practice, the wildcard
expansion code on modern platforms is in some library that can be used
by all applications without violating modularity.  Applications don't
need to invent their own code to deal with this.

In other words, the two different approaches to wildcard expansion
represent two different solutions of the problem.  Each solution has
its advantages and disadvantages; no one, IMHO, is significantly
superior to the other.  The case in point is just one example of
this; there are others.

In fact, this specific issue of what "grep -r" means has generated so
many FAQs that IIRC the latest versions (or maybe the CVS codebase)
introduced an option to do exactly what the OP expected.  Of course,
to use that option, the wildcards should be quoted.  Searching
through all *.c files in a directory tree is simply too frequent a
job in the life of a programmer to ask her to type a find | xargs
pipe each time they need it.  (And using xargs requires on many
systems to know about shell's limits of command-line length, an issue
that is subtle and obscure.)

> GNU grep is a GNU command.  Shouldn't it behave as on a GNU
> system?

It should, no doubts about that.

> > What standard Unix concept am I missing here?
> 
> On UNIX/GNU systems the shell processes wildcards and meta characters
> and does most of the argument handling for all programs uniformly.
> The program gets the expanded argument list and then performs its own
> operations.  Small and modular programs are joined together using
> pipes to create more complex programs.  On DOS programs that do
> everything are common because the platform under it does so little
> that there is no choice.

These are two different issues: what services the underlying OS
offers, and what other utilities are available to work alongside the
application, like the shell and other applications connected through a
pipe.  Wildcard expansion is not an OS service on a Unix system (DOS,
by contrast, does have such as system call, although many applications
don't use it, especially if they want to support Unix-style
wildcards).

> Single large monolithic programs, such as a program which does
> everything, are frowned upon because they violate those principles of
> keep it small, keep it focused on doing one thing well, and design it
> to fit with other programs so that more comlex behavior can be
> created.

Ironically, a typical Unix shell is nowadays anything but small.  On a
random GNU/Linux box, the Bash 2.05 excutable is more than 500KB, and
that's excluding the code from the shared libraries it uses.  The
venerable COMMAND.COM, by contrast, was only a few tens of KBytes.  In
fact, the single most important reason why wildcard expansion was left
out of the DOS shell was to keep the shell small and simple.