Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!xanth!ukma!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!adam.pika.mit.edu!scs From: scs@adam.pika.mit.edu (Steve Summit) Newsgroups: comp.unix.wizards Subject: Re: filename substitution question Message-ID: <10100@bloom-beacon.MIT.EDU> Date: 25 Mar 89 05:37:23 GMT References: <1627@ncar.ucar.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Distribution: usa Lines: 48 In article <1627@ncar.ucar.edu> rob@scdpyr.ucar.edu (Robert Montgomery) writes: >Often it would be simpler to specify what I *don't* want in filename >substitution than what I do. For example, I would like to do something >similar the following: > ls {NOTfrog}.c >and have it produce: > bird.c fish.c A nice solution which I have not seen mentioned yet is the "pick" program, described in Kernighan and Pike's book, The Unix Programming Environment. You always invoke pick inside of backquotes, viz.: command `pick *.c` and you get to answer yes or no for each filename. It'd be silly for the ls example (but then again, so would anything; the problem comes up more typically when the command in question is going to modify the files somehow). pick essentially allows you to add an "inquire" facility to any program; for instance, rm -i * is equivalent to rm `pick *` The only problem with pick is that people who use the MH mail system already have another meaning for the command. For simply listing files, I find that postprocessing (rather than preselecting) is usually more convenient. For example, a frequent idiom of mine is ls -lt | grep -v '\.o$' to see what source files I've changed lately. If you can neither find a copy of Kernighan and Pike (as I recall, it included source code) nor write pick yourself (the only tricky part is using /dev/tty) I can send you my implementation. (I ought to just include it here; it's under 50 lines long.) Steve Summit scs@adam.pika.mit.edu