bruce@zuhause.MN.ORG (Bruce Albrecht) (12/31/90)
>In article <238@coplex.UUCP> dean@coplex.UUCP (Dean Brooks) writes: >However, I was curious, not having used 2.0 yet, does it (2.0) support >real UNIX/regex style pattern matching? That is the only reason for >actually using ARP, and a prety good one at that. Anybody care to >comment? It has real wildcards, but it's not embedded in the standard shell, nor is it in the same format as the Unix wildcards. -- bruce@zuhause.mn.org
dean@coplex.UUCP (Dean Brooks) (01/01/91)
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. However, I was curious, not having used 2.0 yet, does it (2.0) support real UNIX/regex style pattern matching? That is the only reason for actually using ARP, and a prety good one at that. Anybody care to comment? -- dean@coplex.UUCP Dean A. Brooks UUCP: !uunet!coplex!dean
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/01/91)
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. They are just unfamiliar to Unix users. 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. 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, 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. If you don't do that, you get into the situation of the grotesque and effectively unusable quoting conventions of, for example, Unix sh or csh, to pass your wildcards in unmangled, or you have to make up a whole second set of wildcards for your application, even more confusing. > However, I was curious, not having used 2.0 yet, does it (2.0) support > real UNIX/regex style pattern matching? That is the only reason for > actually using ARP, and a pretty good one at that. Anybody care to > comment? 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. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
cosell@bbn.com (Bernie Cosell) (01/01/91)
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(<namewithwildcard>); 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\
farren@well.sf.ca.us (Mike Farren) (01/03/91)
cosell@bbn.com (Bernie Cosell) writes: >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. No. Lots of operating systems which derive from DEC operating systems have it. '*' became popular because it was DEC's preferred universal wildcard symbol, and for no other reason. MS-DOS derives from CP/M, which derives from DEC's OS for the PDP-11. Unix came into existance on DEC equipment, and has many holdovers from DEC practice. >The rest of the Unix file name notation ('?' and [abced]) is really a >loser. Not quite. The regex format allows many nicely precise variants in parameters (not _just_ file names). It's a limitation of the shell which prevents saying, for example, (*.lisp|*.tex), not an inherent limitation in the wildcarding, which is yet another reason to put wildcarding in the executable, rather than in the shell. -- Mike Farren farren@well.sf.ca.us
walt@bcarh133.uucp (Walt Sullivan) (01/05/91)
Dec's TOPS-20 operating system had wildcard expansion built into the operating system, but callable by the program parsing the command line. The COMND JSYS (system call) could be asked to parse all sorts of things - keywordsfrom a table, numbers in bases 2-10, switches from a table, input filespec, output filespec, general (arbitrary) filespec, arbitrary fields, end-of-line, directory name, user name, comma, floating point number, device name, text up to carriage return, date/time, quoted string, string up to one of a set of specified break characters, compare input with a given token, account string, node name and more. Another JSYS (WILD%) allowed comparison of a wildcarded filespec with a non-wildcarded filespec. This allowed any program to make use of a _standard_ set of wildcard parsing and expansion routines, in any desired combination. I'd like to see the Amiga have a wildcard.library that offered similar functionality. I don't think forcing each and every Amiga programmer to invent his/her own set of wildcard parsing/expansion routines (and conventions!) is a good idea. Who knows, I might like '#?', you might like '*', and some other sicko might like '$$ALL-THE-FILES$$' :-) -- Walt Sullivan BITNET: walt@BNR.CA (work) UUCP: walt@orbit.amiga.OCUnix.on.ca (home)
telam@pyrps5.pyramid.com (Thomas Elam) (01/05/91)
In article <WALT.91Jan4220249@bcarh133.uucp> walt@bcarh133.uucp (Walt Sullivan) writes: >Dec's TOPS-20 operating system had wildcard expansion built into the >operating system, but callable by the program parsing the command line. >The COMND JSYS (system call) could be asked to parse all sorts of things >- keywordsfrom a table, numbers in bases 2-10, switches from a table, >input filespec, output filespec, general (arbitrary) filespec, arbitrary >fields, end-of-line, directory name, user name, comma, floating point >number, device name, text up to carriage return, date/time, quoted >string, string up to one of a set of specified break characters, compare >input with a given token, account string, node name and more. Another >JSYS (WILD%) allowed comparison of a wildcarded filespec with a >non-wildcarded filespec. > >This allowed any program to make use of a _standard_ set of wildcard >parsing and expansion routines, in any desired combination. > >I'd like to see the Amiga have a wildcard.library that offered similar >functionality. Maybe even more than one (e.g. unix_shell_pattern.library and amiga_shell_pattern.library) AND/OR switches to the library to change global AND/OR local selection of pattern types. (I don't know which I would like better, alternate libraries or switches to a single library.) >I don't think forcing each and every Amiga programmer to invent his/her >own set of wildcard parsing/expansion routines (and conventions!) is a >good idea. Who knows, I might like '#?', you might like '*', and some >other sicko might like '$$ALL-THE-FILES$$' :-) > > >-- >Walt Sullivan >BITNET: walt@BNR.CA (work) >UUCP: walt@orbit.amiga.OCUnix.on.ca (home)
daveh@cbmvax.commodore.com (Dave Haynie) (01/08/91)
In article <WALT.91Jan4220249@bcarh133.uucp> walt@bcarh133.uucp (Walt Sullivan) writes: >Dec's TOPS-20 operating system had wildcard expansion built into the >operating system, but callable by the program parsing the command line. >I'd like to see the Amiga have a wildcard.library that offered similar >functionality. Under 2.0, DOS library has functions which do full wildcard parsing and matching. So all 2.0 commands call these routines. Any programmer can use them, on the command line, within a GUI-based program, wherever. Those who like shells to do the command line expansion should be able to get shells that uses these 2.0 routines before long. Of course, they'll have to learn when to quote for each command used, whereas normal shells leave it to the command to know what needs to be expanded in what way. >I don't think forcing each and every Amiga programmer to invent his/her >own set of wildcard parsing/expansion routines (and conventions!) is a >good idea. It isn't, really. I don't think its been at the "create your own" routine level for some time. At least Lattice gave you the primitive "?*" or "#?" matching conventions. There have been two PD routine sets out there, (I wrote one that compiles under Lattice) that do full 1.3 convention pattern matching, and there's ARP, so it has been awhile since anyone needed to reinvent the wheel. Of course, centralizing it under 2.0 make it possible to change the convention everywhere should someone find that necessary. >Walt Sullivan -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley