www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Command-line arguments

reply superdan <super dan.org> writes:
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 :)
Jul 06 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
Jul 06 2008