Command-line arguments

[superdan]

Steven Schveighoffer Wrote:

> "superdan"  wrote
> > Steven Schveighoffer Wrote:
> >
> >> "superdan" wrote
> >> > Bill Baxter Wrote:
> >> >
> >> >> Jarrett Billingsley wrote:
> >> >> > "Matt" <no-one at none.nowhere.com> wrote in message
> >> >> > news:g4jqum$269v$1 at digitalmars.com...
> >> >> >> Is there an established library in D for handling command-line
> >> >> >> arguments?
> >> >> >>
> >> >> >> In particular:
> >> >> >> - handling differences between Windows and UNIX shells (i.e. 
> >> >> >> wildcard
> >> >> >> expansion)
> >> >> >> - handling equivalent options such as "-n 10" === --count=10
> >> >> >> - handling combination of multiple flags, e.g. "-lcf" == "-l -f -c"
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Matt
> >> >> >
> >> >> > I don't believe there is an argument parser in either Phobos 1 or
> >> >> > Phobos 2.
> >> >> > However, there is one in Tango.
> >> >> >
> >> >> >
> >> >>
> >> >> doost has one that works with Phobos. 
> >> >> (http://dsource.org/projects/doost)
> >> >>
> >> >> D2/Phobos2 has std.getopt.
> >> >>
> >> >> There's a port std.getopt to D1 in the std2 project:
> >> >> http://www.dsource.org/projects/std2
> >> >>
> >> >> There's a simple port of BSD's getopt in OpenMesh/D:
> >> >> http://www.dsource.org/projects/openmeshd/browser/trunk/OpenMeshD/OpenMesh/Tools/Utils/getopt.d
> >> >>
> >> >> --bb
> >> >
> >> > there's one in tango too but it takes 20 lines to do anything, as most
> >> > others do. create a freakin' "command line object". give me a lunch 
> >> > break.
> >> > std.getopt in phobos is best in the world for my money. and across all
> >> > languages for that matter. could never imagine do so much shit in one
> >> > call.
> >>
> >> 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. 

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

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

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

> That being said, you have some valid points.  For instance, if you are 
> parsing an integer argument, it is tedious to always have to deal with a 
> string that might not be an integer.  And the speicifcation of long/short 
> options together + aliases is very attractive.  However, I think these 
> concepts could be incorporated into Arguments with not a lot of effort. 
> I'll file a ticket about it with Tango.

yeah tell them to make that trunk a little higher while they're at it. ;)