Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!ucsd!sdd.hp.com!wuarchive!ukma!usenet.ins.cwru.edu!ncoast!davewt From: davewt@NCoast.ORG (David Wright) Newsgroups: comp.sys.amiga.tech Subject: Re: Wildcard types Summary: One of the things that ARP did right.... Keywords: ARP, command line parsing Message-ID: <1990Nov19.044047.850@NCoast.ORG> Date: 19 Nov 90 04:40:47 GMT References: <1990Nov16.171451.5668@gtisqr.uucp> <1990Nov16.234820.14783@msuinfo.cl.msu.edu> Organization: North Coast Public Access *NIX, Cleveland, OH Lines: 36 In article ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) writes: >The biggest problem with leaving wildcard expansion up to each application >is that it means each application needs to do the job in exactly the same >way in order to provide a consistent environment. > ...... >With the shell doing the expansion, individual cmds need only be designed >to handle multiple agruments. > ...... >Granted, shells will need maintenance to accomodate such new features too, >but with shells doing the expansion, it only need to be done in ONE place >(per shell) with the change being "transparent" to (most) commands. Haven't you ever programmed with ARP? One of the best things that ARP did (and the only one that I wish was included in 2.0 (anyone know if the source to gads() will be released seperately? (or added to 2.1???))) was the removal of the clumsy argc/argv[] of normal C. ARP gave you PREPARSED command lines. This meant that you could specify that argument 2 was a switch, and no matter what order the user entered arguments to your program, the arguments were parsed and placed in the correct "element" of the argv[] array. If one of the arguments supported wildcards, that argument returned a *pointer to another array*, which contained all the filenames that matched. This meant that the APPLICATION programmer could decide on how to handle wildcards, that the shell did not have to, and that the wildcard code was in ONE PLACE, and changing/enhancing it would automatically fix the programs that used it, as it was a shared library. Additionally, it took care of allocating the memory to hold the file name array, and reading the disk for the files to fill it, so the shell wasn't hung-up doing this and could let you start up something else. Of all the features of ARP I wish were in 2.0, only the gads() command line handler (and maybe their nice resource tracking features) are really worth the effort, and are also the only reason I might still consider using ARP for future products... Dave