Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ucsd!usc!cs.utexas.edu!uunet!bu.edu!bbn.com!cosell From: cosell@bbn.com (Bernie Cosell) Newsgroups: comp.sys.amiga Subject: Re: Does 2.0 have REAL wildcards? (was Re: VLT Help needed) Message-ID: <61799@bbn.BBN.COM> Date: 1 Jan 91 15:42:27 GMT References: <8pwxo8v@Unify.Com> <1990Dec30.163531.22293@zorch.SF-Bay.ORG> <238@coplex.UUCP> <1991Jan1.052216.672@zorch.SF-Bay.ORG> Sender: news@bbn.com Distribution: na Lines: 107 xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: }dean@coplex.UUCP (Dean Brooks) writes: }>xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: }>> "ARP" is the AmigaDOS Replacement Project, a cooperative PD code }>> effort that got off to a fair start, but died for lack of interest }>> with the code still buggy and the source unavailable to fix it up. It }>> had the advantage that the library and executables were small and did }>> a few nice things that AmigaDOS didn't, the _BIG_ disadvantage that }>> they were incompatible with the CLI script and wildcard formats. }> Well, hoorah for ARP then. Standard AmigaDOS (1.2/1.3) has had brain }> dead pattern matching from the beginning, with not supporting standard }> conventions, and placing the pattern matching code within the }> executables, rather than the console device. }Horrible embarrassing confession time. I once held such opinions, and }even espoused them right here in comp.sys.amiga. I was wrong, and I got }educated out of my ignorance by people on the net. The Amiga wildcards, }compared to the Unix wildcards, are more "correct", more powerful, and }more convenient. ... Kudos --- this is one of the best summaries of the state of wildcardness that I've seen. I hesitate to prolong this thread [since you've really done a good job of dispatching the matter, but: }There are }no "standard conventions"; you just think your piece of the elephant is }all the elephant there is. When you become completely familiar with the }Amiga conventions, you wish you had them in Unix. Sigh. Tiny nit --- this is not quite right. OS's have used '*' for 'all' for a VERY long time, and lots of OS's do it. Usually, however, it has been confined to 'field oriented' file names, where '*' only wildcards a single field at a time, and so in MSDOS you get things like "*.*", and in TOPS-10 [*,*] is a ppn. I'd have to say that '*' to wildcard a *field* in a file name really is pretty much a standard convention... The rest of the Unix file name notation ('?' and [abced]) is really a loser. It only makes a smidgeon of sense in the very-old unix world where most file types had one-char "extensions" [.o, .c, .y, etc], and so things like "pr *.[ch]" were reasonably natural. Once you go beyond that and allow REAL file names [.lisp, .tex, etc] the feebleness of the Unix convention becomes REAL apparent... }To your second point; wild card expansion _belongs_ in the executable }rather than in the shell. It would be nice if the normal case could be }punted right back out to a resident library to save wheel reinvention, I think this is not 'nice', but ESSENTIAL. Leaving it up tto the applications programmer [the way Unix did for command-line-switches, and the way AMIGADos did for things like the file requester] is a 100% loser. There are two big advantages of doing it in the OS [where a shared library is just one implemenation of 'doing it in the OS'], and avoiding reinventing the wheel is not really one of them: (1) *every* program will _do_ wildcards [this universality is really important, and conversely the uncertainly of not knowing if one Amiga program or another actual DOES wildcards is a pain in the neck], aND (2) they're always done the same way [and again, for all of its warts, at least by having the shell expand wildcards means that the expansion is _predictable_. Will the expansion include '.' files? Will it expand across directories, etc at least you can learn it Once, and then you know it, ditto for thequoting conventions and such] A third advantage is that it is available to programs. I've actually written the 'C' code on Unix to do use a popen ("ls *.foo", "r") to get a wildcard expanded within a program. How much I wished I could just do openfirst(); opennext(); opennext(); etc Another advantage is that it can work over arbitrarily large wildcard expansions. I regularly get 'arg list too long' errors on Unix, and that just doesn't happen when the OS expands your wildcard one at a time. There is also a speed advantage: when your wildcard expands over a huge amoung of stuff [or on a slow device, like a floppy], you dont' get the BIG startup delay in your program. }but the point has been well made here that files are by no means the only }things one might want to resolve with wildcards, and so you daren't do }the resolution and lose the wildcards before the application executable }has had a shot at it as it was typed. By deferring the resolution to the }executable, you allow, for example, a database access to resolve the same }familiar wildcards into sets of records instead of sets of files. Oh yes, the list of the neat things you can do goes on and on [e.g., to allow different search paths for different types of expansions [consider the '-I' path for .h files versus the path used for '-l' libs in your C compiler, versus TEXINPUTS, versus...] Or the application may want to mess with the file name [e.g., as in RCS to append a ',v'], Or.... }I understand that you can set a flag in one or more of the beta releases of }2.0 to enable specifically the Unix "*" as an alias for the AmigaOS "#?", }but this just causes you problems with "*" as a quoting character, so, for }the reasons noted above, you're better off not using it. I think that this flag is probably a good thing --- as I mentioned above, about the only part of the Unix wildard convention with pretentions to 'standardness' [not to mention 'usefulness'] is "*" for "all", and defining * -> #? is a pretty good tradeoff. By contrast, _I_ happen to find the BCPL '*'-quoting convention something I'd be happy to see go away. /Bernie\