Command-line arguments

[Steven Schveighoffer]

"superdan" wrote
> Steven Schveighoffer Wrote:
>
>> "superdan" wrote
>> > Steven Schveighoffer Wrote:
>> >
>> >> "superdan"  wrote
>> >> > Steven Schveighoffer Wrote:
>> >> >> There is a new one in Tango as of the latest release called 
>> >> >> Arguments.
>> >> >> It's
>> >> >> very simple to use:
>> >> >>
>> >> >> auto args = new Arguments(argv[1..$]);
>> >> >>
>> >> >> if(args.contains("c")) {} // test for -c
>> >> >> auto filename = args["f"]; // get parameter for -f filename
>> >> >>
>> >> >> Of course, you can also configure it to be more strict, or to 
>> >> >> change
>> >> >> every
>> >> >> detail, down to the switch character (instead of '-'), but it is 
>> >> >> easy
>> >> >> to
>> >> >> use
>> >> >> to get something up and running quickly.
>> >> >>
>> >> >> http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html
>> >> >
>> >> > yarp looked over it. with all due respect, what a piece of crap that
>> >> > is.
>> >> > with that i can't even hope to parse the command line of ssh or 
>> >> > rdmd.
>> >> > it
>> >> > loses the original order. it doesn't understand -- which in unix 
>> >> > means
>> >> > that options stop here. generally does not obey new unix 
>> >> > conventions.
>> >> > defines all sort of useless shit like conflicts that i could care 
>> >> > less
>> >> > about. i could write one test expression after parsing thank you 
>> >> > very
>> >> > much. but it cannot force the types of its arguments so i must make
>> >> > sure i
>> >> > validate /all/ that shit which is much more voluminous. geez. 
>> >> > finally
>> >> > it
>> >> > defines so many types and functions anyone will need a fucking 
>> >> > graduate
>> >> > course to use it. no thanks. std.getopt mops the floor with it.
>> >>
>> >> Piece of crap is a little harsh :)
>> >
>> > i agree it is harsh but i am dead serious. the problem is, tango people
>> > should not allow people who can't design add stuff to tango. i look at
>> > both option parsing stuff in tango and i get thinkin' of american 
>> > sedans.
>> > you look at an american sedan and you clearly can say it looks like a
>> > vicious piece of shit. but it's hard to tell why. maybe if they raised 
>> > the
>> > trunk a little? the headlights should be placed differently? no idea. 
>> > it
>> > just sucks ass because it's designed by someone who can't design. the
>> > design is so messed up you can't pinpoint a couple of flaws. the right
>> > solution is to throw the whole thing and bring in someone who can 
>> > design.
>>
>> I happen to think it is well-designed for being as flexible as it is. 
>> Like
>> many things in Tango, it has the ability to adapt to 95% of requirements 
>> and
>> still be easy to use.  I stopped using Phobos after about a week because 
>> in
>> order to support the types of things I was doing with sockets, I needed
>> functions that Phobos didn't abstract.  Tango handled the job extremely
>> well, and I can't say I miss anything in Phobos.
>
> that is an issue in phobos not an issue in getopt. didn't say phobos is 
> bigger & better than tango. just that std.getopt is much better than any 
> other offering. since you brought up phobos in its entirety. the new stuff 
> in phobos2 beats the pants off any offering in tango or elsewhere. it's 
> like shakespeare vs. the million monkeys. but agreed it has a ways to go. 
> there's too much stuff that just ain't there :)
>
> anyhoo if you could please write tango code for parsing that ssh command 
> line we could compare apples w/ apples. here 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=73311

Sure:

int main(char[][] args) // Tango, so we are D1 style
{
  args = args[1..$];
  bool f(char[] a) { return a.length && a[0] != '-';}
  auto offset = args.findIf(&f);
  if(offset == args.length)
  {
     Stderr("Hostname not specified");
     return 1;
  }
  auto host = args[offset];
  auto cmdidx = offset + 1 + args[offset + 1..$].findIf(&f);
  auto arguments = new Arguments(args[0..cmdidx]);
  uint verbosityLevel = arguments.count("v");
  // get other arguments
  if(cmdidx == args.length)
    // start shell
  else
    // run command on host.
}

Note, not tested.

>
>> >
>> >>  It can do some things that std.getopt
>> >> cannot, and the interface is loads better than the original ArgParser
>> >> that
>> >> Tango had.
>> >
>> > to be 100% honest the original stuff that ArgParser had set the bar 
>> > real
>> > real low. and again. maybe an american sedan could do something that
>> > others can't. maybe it has a neat ac control or a cool steering wheel 
>> > or
>> > shit. would i drive such a piece of shit for that? hell no.
>>
>> The defaults for Arguments are really easy to use and follow the unix 
>> style.
>> You have pointed out several things missing from the implementation that 
>> can
>> easily be added.  In addition, Arguments has lots of extra features that 
>> can
>> be useful if you need to have them.
>
> like what.

Like specifying how many arguments a command line option requires.  Or 
specifying validation of an argument so it is done while parsing.

>
>> And let's stop the whole car analogy.  If I get a shitty ac control on a
>> car, I'm pretty much stuck.  Code can always be changed/added to :)
>
> alrighty.
>
>> >
>> >>  The issue I have with getopt is that it forces you into a
>> >> specific option style.  This can be unacceptable if you are required 
>> >> to
>> >> use
>> >> another style (by your employer for instance).
>> >
>> > if your employer wants to override tried and true de facto standards 
>> > then
>> > it's their problem. that comes with custom code for handling args, 
>> > steeper
>> > learning curve for use, and more user annoyance. i fail to see how 
>> > that's
>> > a problem with std.getopt.
>>
>>
>> Try using std.getopt with a windows application where the requirements 
>> state
>> that you have to use '/' instead of '-' for arguments.  And telling your
>> employer/client to go screw because they are idiots for not realizing 
>> POSIX
>> style arguments are God's gift to man doesn't usually blow over well.
>
> good point. i also think getopt should have '-' configurable. maybe even 
> '--'. i see they're enums now. should be module vars.
>
>> This is very simple in Arguments.  I agree that getopt is well-designed 
>> if
>> the unix style of arguments is exactly what you want.  But if it isn't, 
>> you
>> must write your own (or use Tango).  I prefer not to reinvent the wheel 
>> for
>> every application.
>
> @ the risk of anticipating (i've read ur entire post before answering): 
> you say yourself features are not necessarily design. this is a feature 
> thing.

This is your side of the fence :)  Remember, you started this by saying 
Arguments had a shitty design.

If we can all agree that both Arguments and getopt are well designed 
concepts which are each missing a couple features, then I will accept that. 
Where they differ is in style of the interface to them, which I am assuming 
you like the getopt interface better.

>
>> >
>> >> Plus, with all the arguments
>> >> contained in one object, and all the validation being configurable on 
>> >> the
>> >> object instead of writing some piece of code after parsing, the 
>> >> arguments
>> >> can be very modularized, and reduced to simple functions.
>> >
>> > "modularized"? there is one command line per app. there is no need to
>> > modularize anything. you modularlize if you use several instances in
>> > several places. with command parsing all i want is to parse my args and
>> > move on. in fact i *want* to put my validation right there in clear
>> > instead of modularizing it away.
>>
>> What about standard options?  GNU has these, and why should you rewrite 
>> the
>> same code for every app?
>
> you put those in a function. getopt allows multiple passes through the 
> flag passThrough. cool if you ask me.

That's cool.  Not having used getopt, I don't know all the nuiances.

-Steve