🚀 go-pugleaf

In article <a9rK02ZFe8RI01@amdahl.uts.amdahl.com> 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