Command-line arguments

superdan super at dan.org
Sun Jul 6 08:23:40 PDT 2008


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

> >
> >>  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.

> 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.

> >
> >> 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.

> >> BTW, does getopt preserve order?  It doesn't look like it from the docs.
> >
> > no but it understands -- and also has stopOnFirstNonOption. that's all 
> > that's needed.
> 
> This behavior can be added easily enough.  Again, you point out features of 
> getopt that are not features of Arguments, but are not prevented by the 
> design of Arguments from being added.  These are 'feature' requests, not 
> 'design' requests.

yarp here's where you are caught arguing both sides of the fence :)




More information about the Digitalmars-d mailing list