lphillips@lpami.wimsey.bc.ca (Larry Phillips) (03/10/90)
In <5369@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > >*when* I get my Amiga back up to multiple megabytes, I'll make parseargs a >library routine. And provide two versions. So programs that use wildcards >will be simply able to do: > >main(ac, av) >int ac; >char **av; >{ > parseargs(av, ad); > >} > >And folks with "unixargs.library" will get UNIX arguments and wildcards, and >folks with "amiargs.library" will get AmigaDos arguments and wildcards. You >can already do the argument part with the version of parseargs I sent to >comp.sources, and getting the wildcards right is just a SMOP. Wonderful! Looking forward to it. Will you include the option to alow wildcard matching against arbitrary data? I haven't looked at parseargs yet, so the above question may reflect that. What I mean is, could I send argv[1] for expansion against the contents of a directory, and then send argv[2] for expansion against the expanded argv[1]? -larry -- Entymology bugs me. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (03/10/90)
> Quick: how do you get a ".*" to a sed being run from a shell script > run via 'system' from the program you're actually invoking? If the script is competantly written (i.e., it uses "$@" or "for i" and quotes arguments itself), system("command '.*'"); Arguing from the basis that buggy software makes things harder is a double edged sword, I agree. But at least it's easier to fix the script than someone's mondo uncommented pseudo-basic C code. *when* I get my Amiga back up to multiple megabytes, I'll make parseargs a library routine. And provide two versions. So programs that use wildcards will be simply able to do: main(ac, av) int ac; char **av; { parseargs(av, ad); } And folks with "unixargs.library" will get UNIX arguments and wildcards, and folks with "amiargs.library" will get AmigaDos arguments and wildcards. You can already do the argument part with the version of parseargs I sent to comp.sources, and getting the wildcards right is just a SMOP. In the meantime, parseargs is a way better way of implementing command line arguments than getopt. You merely have to relink the program to switch back and forth. Kudos to Eric Allman. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
peter@sugar.hackercorp.com (Peter da Silva) (03/11/90)
> Wonderful! Looking forward to it. Will you include the option to alow wildcard > matching against arbitrary data? I can package the internal routines conveniently for this. They don't yet exist, so that point's moot. > What I mean is, could I send argv[1] for > expansion against the contents of a directory, and then send argv[2] for > expansion against the expanded argv[1]? Parseargs works by extracting strings from the argument list and sending them to the appropriate routine. For example, if you have defined that "File" or '-f' is a Filename, then the associated string (from the argument, in UNIX style parsing, or the following argument, in Amiga style parsing) gets sent to a routine (yet to be written) calls argFile. in UNIX this will be the same as the String routine, argStr. In Amiga this will do either UNIX or Amiga wildcards and return a list of matching file names. So, define your argFile2 routine to do some preprocessing and call argFile and everyhing automagically works the way you want... Grab the code and check it out. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'