in reply to Re^7: how to deal with 20 commands
in thread how to deal with 20 commands

Sure! Take for example the code in getopt(3) (I'm not posting it here in full because it's longish). Note how you have, essentially,

#include <stdio.h> #include <getopt.h> int main (argc, argv) int argc; char **argv; { /* ... */ getopt_long (argc, argv, "abc:d:012", /* short spec */ long_options, &option_index); /* ... */ }

The "argc" and "argv" you're passing the library function getopt_long just happen to be the ones given to you on the command line. But if you'd have constructed any other, er, argument vector, you could have passed that instead.

The same thing happens in Java, when your entry point accepts a String args[], and passes that (or a different String[]) to the options parsing library.

Replies are listed 'Best First'.
Re^9: how to deal with 20 commands
by thor (Priest) on May 24, 2005 at 11:18 UTC
    Ah...I see what you're saying now. You want the ability to have the arguments parser act upon arbitrary arrays as opposed to always acting on @ARGV. If this gets implemented, I'd sure like to see @ARGV be the default. Because, just like in the examples that you site above, @ARGV will be what 99.99% of the people want. Of course, the devil's in that extra 0.001%. Something in the back of my mind tells me that Perl6 has multi-dispatch ala Java where you can have mutliple subroutines called the same thing, but the one that gets called is the one that has the right signature. If this is the case, you could do something like:
    sub GetOpts() { GetOpts(@ARGV); } sub GetOpts(@array) { #the real work is done here }

    thor

    Feel the white light, the light within
    Be your own disciple, fan the sparks of will
    For all of us waiting, your kingdom will come

      Sure.

      In Perl 6, That would probably be spelled:

      sub GetOptions(?@args = @*ARGS is rw) { ... } This is so easy to do (it isn't that much harder in Perl 5!), it's a pity it wasn't done already.