Xref: utzoo comp.arch:20204 comp.os.misc:1457 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.arch,comp.os.misc Subject: Re: UNIX mind-set -> OK, OK! Message-ID: <1991Jan15.033636.24714@Think.COM> Date: 15 Jan 91 03:36:36 GMT References: <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> Sender: news@Think.COM Followup-To: comp.os.misc Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 118 [I've followed someone else's lead and directed followups to comp.os.misc.] In article bson@ai.mit.edu (Jan Brittenson) writes: >In article <1991Jan14.170115.17178@Think.COM> > barmar@think.com (Barry Margolin) writes: > > I've used several systems (Multics, ITS, TOPS-20) where the commands > > invoked the globbing routine, ... Filename arguments that don't make > > sense to be wildcards (e.g. the last argument to mv) are scanned for > > wildcard characters, and generate an error if any are seen > > The Unix approach have its advantages sometimes. Assume you have >the files "L19901200.axx772" and "L19910100.bxx19974". If you wish >overwrite the second file with the first it makes sense to use > > mv L*72 L*74 > >if that's unique enough. Another case is cd. When you have only file, >and it's a directory, "cd *" makes sense. If I have a list of files >and like to see if L199901200.axx772 has been backed up, it makes >sense to use the command I admit that I make use of wildcards as convenient way to abbreviate filenames, and when I used Multics I sometimes even wished that its "cd" equivalent allowed this. However, I don't think this is a good excuse for such a poor user interface design. The "cd" command can warn if the wildcard expands into multiple filenames, since it only allows one argument; however, in the "mv" case, such a mistake can result in completely unexpected behavior with no warning. In my opinion, an interactive mechanism is a much better basis for an abbreviation design. For instance, you could type "L*74" and then hit a control or function key that would cause the string to be replaced by the matching filenames (or maybe it would beep if the wildcard matches multiple files). > grep -l L*772 L*backup > >to get a list of what backup file lists it appears in. This >orthogonality is quite a strength of Unix. Granted, there's an almost >infinite potential for error, with no recovery. The fact that you can find a use for a weird behavior doesn't mean that behavior is a good feature. Which is more useful: grep -l L*772 L*backup or grep #define.*EXT *.c *.h > > Putting the work in the utility allows useful syntaxes such as: > > > > mv * =.old > > This is something I quite miss. But I'd rather see it solved in the >shell than in the tools, perhaps as variation of the {...} syntax. Say >that {:re} were made a regex quote, then one could write something >like: > > mv {:\(^.+\)$ \1.old} This violates your point that just changing the shell would be enough: mv(1) doesn't accept multiple old/new filename pairs. The argument syntaxes of most Unix commands are designed based on the kinds of expansions that Unix shells are expected to provide; since the shells are known not to provide the above expansion, no commands are prepared to accept such arguments. > I guess every Unix programmer has at some point wished there was a >sh-compatible glob(3) for some very specific purposes, though. Yes! Many programs allow filenames to be specified interactively; if they want to allow these filenames to be wildcards and be sure of sh-compatibility, they have to fork a subshell, pipe the output of echo, and parse the result (and this won't work if any of the matching files have spaces in their names). Also, one might want to perform wildcard matching on names of other things besides files. > > If there's a reasonable library routine available, the hardest part > > should be deciding which arguments should be processed as wildcards. > > It really doesn't make much difference whether it's in a library or >in a shell, really, as long as there are sufficient hooks for >redefining the syntax. I mean, instead of escaping don't-matches, you >end up escaping do-matches to tell the globber you do want a specific >argument globbed regardless of what the tool thinks is appropriate. True. For instance, in your above grep command, you could do: grep -l `ls L*772` L*backup > In Unix hooks really aren't necessary, as you can switch shells >easily, or implement a different syntax in your application and be >sure nothing is globbed following exec(2). You can't really switch shells all that easily. On many Unix systems, you can only make a shell your default shell if it is in your system's /etc/shells. > > I agree, it isn't cat's job [to glob]. However, it would be the job > > of a wildcard_match() library routine, which would take a wildcard > > argument and return an array of filenames. It would be cat's job to > > call this for its filename arguments. > > I'm not sure how feasible this is. In order to handle `command` >constructs you would need to include an entire shell, more or less. Or >you could start a subshell, in which case we're back where this >discussion started. (Should the subshell call wildcard_match()?) I don't consider `command` the same as globbing. It's part of the shell syntax, as are alias and variable expansion. The difference between these and wildcard expansion is that the latter is much more context-dependent, since it is specific to filename arguments. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar