Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!pyramid!leadsv!laic!nova!darin From: darin@nova.laic.uucp (Darin Johnson) Newsgroups: comp.sys.amiga Subject: Re: AmigaDos vs Unix wildcards/pathnames Message-ID: <483@laic.UUCP> Date: 21 Mar 89 18:28:07 GMT References: <11241@ut-emx.UUCP> <6306@cbmvax.UUCP> <353@bnr-fos.UUCP> Sender: news@laic.UUCP Reply-To: darin@nova.UUCP (Darin Johnson) Organization: Lockheed AI Center, Menlo Park Lines: 66 In article shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >In article <353@bnr-fos.UUCP> schow@bnr-public.uucp (Stanley Chow) writes: > >>In particular, the Unix convention of expanding wildcard in the shell >>strikes me as very silly. >> Consider the problems of expanding wildcard in the shell: >> - increditably long lines are passed around. > >So? Either the shell builds an incredibly long line and pulls the >parameters from it to pass to the program, or you pass the program the >command line directly (as the CLI does) and the program builds the >same incredibly long line. Big lot of difference it makes. This isn't true. Most OS's that I have seen that support wildcards from within programs (rather than from the shell) have library calls similar to directory reading routines (Examine, ExNext). So you could write a program that expands the wildcards, sticking each new thing onto an ever growing argv list. But even better, if you are writing something that doesn't need every argument before it starts, you can expand the wildcards incrementally, dealing with each argument, tossing it away, getting the next, etc. For example, rm/delete don't need to have every argument before they start deleting things. Of course, if rm had the expanded list, it could actually figure out that a file didn't exist and abort before deleting anything, but it doesn't do that anyway... However, I do like UNIX style wildcards, it's just a bit innefficient. It is handy though. The echo command with wildcards is pretty useful (a cheap version of find). The philosophy deep down is elegant - a command should do the same thing for "rm *.c" or "rm `find -xyz`". (actually, I don't like to use 'elegant' with unix. I don't think it was designed to be elegant as such. Diehards just like to say 'elegant' instead of 'works well with the kludges that are already there'.) >multiple renames such as "rename *.foo *.bar". Big deal. You could >write one if you really wanted to. Granted, the * would have to be >escaped, or you could choose a dif I don't know if it is that big of a deal. As much as I hate VMS, I grudgingly admit there are a few things about it that I really like, and can't live without. One of these is "rename *.c *.old_c". How about "rename *.% *.old_%" or "rename *.* ;1" (give everything a version number of 1)? In unix, I have to do "mkdir old; mv *.c old", or use a foreach statement. Of course, letting each program handle wildcards has a big pitfall, as experienced in some major OS's - the 'semantics' of wildcards can be different for different commands (causes confusion if "cc *.c" and "pascal *.pas" do different things). >(list of csh features/metachars elided) If the CLI had even half of this stuff, people on 512K machines would be in trouble. Most of the stuff is not used in common unix command lines, but is usually in shell scripts (I had to look up the @, how embarassing). The stuff I personally would like would be pipes and job control (the thing I like about & is that you can change your mind halfway through typing the command and not have to re-edit it). I don't really care about the history, since I usually use arrow keys anyway (NEWCON:). VMS uses arrow keys also (another thing I like about it), and the remaining time that I spend on UNIX, I use only a subset of the available history commands. Of course, the point is moot. There are commercial shells that do all this. (now how come I haven't seen TOPS or Lisp machine users clamoring for command and argument completion? That would be a nice hack :-) Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?