www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Command-line arguments

reply Matt <no-one none.nowhere.com> writes:
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
Jul 03 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Matt" <no-one none.nowhere.com> wrote in message 
news:g4jqum$269v$1 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.
Jul 03 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message 
 news:g4jqum$269v$1 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
Jul 03 2008
parent reply superdan <super dan.org> writes:
Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message 
 news:g4jqum$269v$1 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.
Jul 03 2008
next sibling parent superdan <super dan.org> writes:
superdan Wrote:

 Bill Baxter Wrote:
 
 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message 
 news:g4jqum$269v$1 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.

i meant "doing" not "do". shit. you see folks when i focus on not fuckshitting and not using vernacular my grammar nerve gets anesthesia.
Jul 03 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" <super dan.org> wrote in message 
news:g4k9tr$34r$1 digitalmars.com...
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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 -Steve
Jul 04 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "superdan" <super dan.org> wrote in message 
 news:g4k9tr$34r$1 digitalmars.com...
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.
Jul 04 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan"  wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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 :) It can do some things that std.getopt cannot, and the interface is loads better than the original ArgParser that Tango had. 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). 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. BTW, does getopt preserve order? It doesn't look like it from the docs. 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. -Steve
Jul 04 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "superdan"  wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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. ;)
Jul 04 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Steven Schveighoffer Wrote:
 Piece of crap is a little harsh :)


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 think it would help if Tango had a few more core folks available to review contributions, or simply more contributors in general. As it is we're spread pretty thin, and I think our desire for perfection is somewhat mitigated by a desire to encourage contributions, not alienate users, and simply to have needed stuff in the library. It's a difficult line to walk, and perhaps a more formal review process might help somewhat.
  It can do some things that std.getopt
 cannot, and the interface is loads better than the original ArgParser that
 Tango had.


shit for that? hell no. As always, any contributions to Tango are very much appreciated. If you've got a better design, please submit it.
 yeah tell them to make that trunk a little higher while they're at it. ;)

tango.group helps here a bit by aggregating commonly used modules, but as far as I know, no one actually uses it :-) Sean
Jul 04 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:

 tango.group helps here a bit by aggregating commonly used modules, but as
 far as I know, no one actually uses it :-)

And therefore slated for removal. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 04 2008
prev sibling parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from superdan (super dan.org)'s article
 Steven Schveighoffer Wrote:
 Piece of crap is a little harsh :)


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 think it would help if Tango had a few more core folks available to review contributions, or simply more contributors in general. As it is we're spread pretty thin, and I think our desire for perfection is somewhat mitigated by a desire to encourage contributions, not alienate users, and simply to have needed stuff in the library. It's a difficult line to walk, and perhaps a more formal review process might help somewhat.
  It can do some things that std.getopt
 cannot, and the interface is loads better than the original ArgParser that
 Tango had.


shit for that? hell no. As always, any contributions to Tango are very much appreciated. If you've got a better design, please submit it.

yarp i've got one. just copy std.getopt. i know zilch about copyright and shit but as i read it it looks like they're cool if you just give them credit.
Jul 04 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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.
  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. 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 :)
  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. 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.
 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?
 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. -Steve
Jul 06 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
superdan wrote:

 Steven Schveighoffer Wrote:
 
 "superdan" <super dan.org> wrote in message
 news:g4k9tr$34r$1 digitalmars.com...
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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:




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


 
 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.

I suspect you are serious, but it is hard to tell with the above language. Even criticism should try to be respectful. As for Arguments; even though it is present in Tango trunk (and the previous release), it was not announced as it is still expected to go through further review. It is definately easy to use for the usecases I've thrown at it though. As for preserving and enforcing order, that was one of the design goals for this implementation and thus it should be considered a bug if not easily done. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 04 2008
parent reply superdan <super dan.org> writes:
Lars Ivar Igesund Wrote:

 superdan wrote:
 
 Steven Schveighoffer Wrote:
 
 "superdan" <super dan.org> wrote in message
 news:g4k9tr$34r$1 digitalmars.com...
 Bill Baxter Wrote:

 Jarrett Billingsley wrote:
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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:




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


 
 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.

I suspect you are serious, but it is hard to tell with the above language. Even criticism should try to be respectful.

i mean no disrespect. but if something is a piece of crap i will definItely say it's a piece of crap. and yes i am serious when it comes about design.
 As for Arguments; even though it is present in Tango trunk (and the previous
 release), it was not announced as it is still expected to go through
 further review. It is definately easy to use for the usecases I've thrown
 at it though.

that kinda puts the fault on the review process. after having seen the buick 2008, i'd have my doubts about buick 2009. yet another also, have you ever given std.getopt a test drive?
 As for preserving and enforcing order, that was one of the design goals for
 this implementation and thus it should be considered a bug if not easily
 done.

put in layman's terms: making it unusable for applications that launch secondary commands was a design goal. and you seem to prefer defending it as it is. you know what. do me a favor. you keep tango arguments. i'll use std.getopt.
Jul 04 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
superdan wrote:

 Lars Ivar Igesund Wrote:
 
 As for preserving and enforcing order, that was one of the design goals
 for this implementation and thus it should be considered a bug if not
 easily done.

put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.

No. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 04 2008
parent reply superdan <super dan.org> writes:
Lars Ivar Igesund Wrote:

 superdan wrote:
 
 Lars Ivar Igesund Wrote:
 
 As for preserving and enforcing order, that was one of the design goals
 for this implementation and thus it should be considered a bug if not
 easily done.

put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.

No.

then parse this using tango arguments please: ssh -v ls -la thanks.
Jul 04 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
superdan wrote:

 Lars Ivar Igesund Wrote:
 
 superdan wrote:
 
 Lars Ivar Igesund Wrote:
 
 As for preserving and enforcing order, that was one of the design
 goals for this implementation and thus it should be considered a bug
 if not easily done.

put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.

No.

then parse this using tango arguments please: ssh -v ls -la thanks.

Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs. The order is completely preserved and enforcable though. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 05 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Lars Ivar Igesund wrote:
 superdan wrote:
 then parse this using tango arguments please:

 ssh -v ls -la

 thanks.

Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs. The order is completely preserved and enforcable though.

What about "ssh -v -- ls -la", I wonder. Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.
Jul 05 2008
next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 05 Jul 2008 14:32:25 +0100, Christopher Wright  
<dhasenan gmail.com> wrote:

 Lars Ivar Igesund wrote:
 superdan wrote:
 then parse this using tango arguments please:

 ssh -v ls -la

 thanks.

by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs. The order is completely preserved and enforcable though.

What about "ssh -v -- ls -la", I wonder. Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.

Documents (and requirements specs) can have bugs too.
Jul 05 2008
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Christopher Wright wrote:

 Lars Ivar Igesund wrote:
 superdan wrote:
 then parse this using tango arguments please:

 ssh -v ls -la

 thanks.

Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs. The order is completely preserved and enforcable though.

What about "ssh -v -- ls -la", I wonder. Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.

I agree that part should be available to the user. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jul 05 2008
prev sibling parent superdan <super dan.org> writes:
Lars Ivar Igesund Wrote:

 superdan wrote:
 
 Lars Ivar Igesund Wrote:
 
 superdan wrote:
 
 Lars Ivar Igesund Wrote:
 
 As for preserving and enforcing order, that was one of the design
 goals for this implementation and thus it should be considered a bug
 if not easily done.

put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.

No.

then parse this using tango arguments please: ssh -v ls -la thanks.

Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs. The order is completely preserved and enforcable though.

rats! i forgot the hostname indeed. ok let me fix: ssh -v host ls -la my question is, assuming all bugs are fixed, how does the code for parsing this look like with tango arguments? to make things more interesting, let's use this example: ssh -v host -v ls -la everything before and after host but before command is an option for ssh. everything after command is passed to the command. could you show how this is coded (assuming bugs are fixed) in both tango arguments apis. thanks. here's my std.getopt implementation for the example. let's see how others fare. void main(string[] args) { auto offset = find!("a.length && a[0] == '-'")(args) - begin(args); enforce(offset != args.length, "Hostname not specified"); auto host = args[offset]; args = args[0 .. offset] ~ args[offset + 1 .. $]; uint verbosityLevel; ............ getopt(args, std.getopt.config.stopOnFirstNonOption, "v+", &verbosityLevel, ......... more stuff ......); if (args.length) { ........... start shell session on host ......... } else { ........... run command on host .......... } }
Jul 05 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g4ju5s$2dh0$1 digitalmars.com...
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.

Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes. (I'd link to it, but it was on GotDotNet, which MS replaced with something else and didn't move this particular program over. So I'm attaching the lastest version I have (only about 11k), even though there are newer versions...somewhere.) Just check out how awesomely simple it makes this sample case: BEGIN CODE class WCArguments { public bool lines; public bool words; public bool chars; [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)] public string[] files; [Utilities.CommandLineArgument(Utilities.CommandLineArgu entType.AtMostOnce, ShortName = "num")] public int number; public string[] junk; } class WC { static void Main(string[] args) { WCArguments parsedArgs = new WCArguments(); if (!Utilities.Utility.ParseCommandLineArguments(args, parsedArgs)) { // error encountered in arguments. Display usage message System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments))); } else { // insert application code here } } } END CODE The WCArguments class is itself the very definition of the program's command-line arguments. And attributes can be used to specify things like "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce", "ShortName", "Required", etc. Later versions include automatically-generated help screens. And the command-line syntax is the same ultra-clean-consistent-and-unambiguous commandline syntax that MS's command-line .NET tools use. D2 could probably come close to this with its compile-time reflection, but I don't think there'd be a comparably simple way to specify the things that this uses attributes for.
Jul 03 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:g4k93l$1mh$1 digitalmars.com...
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:g4ju5s$2dh0$1 digitalmars.com...
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.

Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes. (I'd link to it, but it was on GotDotNet, which MS replaced with something else and didn't move this particular program over. So I'm attaching the lastest version I have (only about 11k), even though there are newer versions...somewhere.) Just check out how awesomely simple it makes this sample case: BEGIN CODE class WCArguments { public bool lines; public bool words; public bool chars; [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)] public string[] files; [Utilities.CommandLineArgument(Utilities.CommandLineArgumentType.AtMostOnce, ShortName = "num")] public int number; public string[] junk; } class WC { static void Main(string[] args) { WCArguments parsedArgs = new WCArguments(); if (!Utilities.Utility.ParseCommandLineArguments(args, parsedArgs)) { // error encountered in arguments. Display usage message System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments))); } else { // insert application code here } } } END CODE The WCArguments class is itself the very definition of the program's command-line arguments. And attributes can be used to specify things like "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce", "ShortName", "Required", etc. Later versions include automatically-generated help screens. And the command-line syntax is the same ultra-clean-consistent-and-unambiguous commandline syntax that MS's command-line .NET tools use. D2 could probably come close to this with its compile-time reflection, but I don't think there'd be a comparably simple way to specify the things that this uses attributes for.

I just took a look at Phobos2's getopt. It's impressively code to this in functionality. But I still think this is much cleaner and more DRY ("drier"?)
Jul 03 2008
parent reply superdan <super dan.org> writes:
Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:g4k93l$1mh$1 digitalmars.com...
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:g4ju5s$2dh0$1 digitalmars.com...
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.

Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes. (I'd link to it, but it was on GotDotNet, which MS replaced with something else and didn't move this particular program over. So I'm attaching the lastest version I have (only about 11k), even though there are newer versions...somewhere.) Just check out how awesomely simple it makes this sample case: BEGIN CODE class WCArguments { public bool lines; public bool words; public bool chars; [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)] public string[] files; [Utilities.CommandLineArgument(Utilities.CommandLineArgumentType.AtMostOnce, ShortName = "num")] public int number; public string[] junk; } class WC { static void Main(string[] args) { WCArguments parsedArgs = new WCArguments(); if (!Utilities.Utility.ParseCommandLineArguments(args, parsedArgs)) { // error encountered in arguments. Display usage message System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments))); } else { // insert application code here } } } END CODE The WCArguments class is itself the very definition of the program's command-line arguments. And attributes can be used to specify things like "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce", "ShortName", "Required", etc. Later versions include automatically-generated help screens. And the command-line syntax is the same ultra-clean-consistent-and-unambiguous commandline syntax that MS's command-line .NET tools use. D2 could probably come close to this with its compile-time reflection, but I don't think there'd be a comparably simple way to specify the things that this uses attributes for.

I just took a look at Phobos2's getopt. It's impressively code to this in functionality. But I still think this is much cleaner and more DRY ("drier"?)

in the words of the annoying chick in friends: oh....... my....... god! how could that dung be better than this? void main(string[] args) { bool lines = true, words = true, chars = true; string[] files; int number; getopt(args, "lines", &lines, "words", &words, "lines", &lines, "files", &files, "num", &number); ........ } this does everything that does /without/ adding a new class and redundant shit in square brackets. the fact that there could be multiple files is inferred from the type string[]. no new class, no attributes, no mess. shit man that c# stuff really blows. awesomely blows if you wish. how can anyone like that shit. to say nothing about the no-good generated help string that always is too short and uninformative to help shit. p.s. look! i wrote an entire post and no fuck! fuck me but this is weird. oops i fucked up again. :)
Jul 04 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:g4kit6$nuq$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:g4k93l$1mh$1 digitalmars.com...
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
 news:g4ju5s$2dh0$1 digitalmars.com...
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.

Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes. (I'd link to it, but it was on GotDotNet, which MS replaced with something else and didn't move this particular program over. So I'm attaching the lastest version I have (only about 11k), even though there are newer versions...somewhere.) Just check out how awesomely simple it makes this sample case: BEGIN CODE class WCArguments { public bool lines; public bool words; public bool chars; [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)] public string[] files; [Utilities.CommandLineArgument(Utilities.CommandLineArgumentType.AtMostOnce, ShortName = "num")] public int number; public string[] junk; } class WC { static void Main(string[] args) { WCArguments parsedArgs = new WCArguments(); if (!Utilities.Utility.ParseCommandLineArguments(args, parsedArgs)) { // error encountered in arguments. Display usage message System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments))); } else { // insert application code here } } } END CODE The WCArguments class is itself the very definition of the program's command-line arguments. And attributes can be used to specify things like "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce", "ShortName", "Required", etc. Later versions include automatically-generated help screens. And the command-line syntax is the same ultra-clean-consistent-and-unambiguous commandline syntax that MS's command-line .NET tools use. D2 could probably come close to this with its compile-time reflection, but I don't think there'd be a comparably simple way to specify the things that this uses attributes for.

I just took a look at Phobos2's getopt. It's impressively code to this in functionality. But I still think this is much cleaner and more DRY ("drier"?)

in the words of the annoying chick in friends: oh....... my....... god! how could that dung be better than this? void main(string[] args) { bool lines = true, words = true, chars = true; string[] files; int number; getopt(args, "lines", &lines, "words", &words, "lines", &lines, "files", &files, "num", &number); ........ } this does everything that does /without/ adding a new class and redundant shit in square brackets. the fact that there could be multiple files is inferred from the type string[]. no new class, no attributes, no mess. shit man that c# stuff really blows. awesomely blows if you wish. how can anyone like that shit. to say nothing about the no-good generated help string that always is too short and uninformative to help shit. p.s. look! i wrote an entire post and no fuck! fuck me but this is weird. oops i fucked up again. :)

The getopt version forces you to list each variable three times. Once for the variable itself, once more to tell getopt what it's called, and a third time to tell getopt where it is. That's highly redundant. They're only listed once for the C# version. (The getopt version could probably be changed to extract the name from the variable using templates and traits though, and it could probably eliminate the rest of that redundancy by sticking the vars into a class or stuct, but then it would lose the ability to let you specify options for each var. Attributes would bring that ability back without creating reduncancy). Regarding the C# version: - Sticking the variable declarations inside a class is trivial. - All of the stuff in square brackets (attributes) are optional. (If you do specify any attributes, then the AttributeType is required, however I was able to remove that restriction in about two minutes by adding two trivial constructors.) - You can specify a custom help string for each element. - The fact that there could be multiple files *IS* inferred by using an array of strings. (At least if you don't use any attributes, that is. But that can be fixed fairly easily too.) If anyone's interested, I found a link: http://www.codeplex.com/CommandLineArguments
Jul 04 2008
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:
...
 
 The getopt version forces you to list each variable three times. Once for
 the variable itself, once more to tell getopt what it's called, and a
 third time to tell getopt where it is. That's highly redundant. They're
 only
 listed once for the C# version.  (The getopt version could probably be
 changed to extract the name from the variable using templates and traits
 though, and it could probably eliminate the rest of that redundancy by
 sticking the vars into a class or stuct, but then it would lose the
 ability to let you specify options for each var. Attributes would bring
 that ability back without creating reduncancy).

I don't understand why attributes are needed to achieve this. You can indeed use traits (with a mixin) to eliminate the redunancy of getopt, this takes about 20 lines of code at most. With mixin+templates, it should not be too difficult to also let the user specify options per variable. C# attributes as I understand it make use of runtime reflection, D and especially D2 has enough compile time reflection power to make this design work and do so in a less verbose manner.
Jul 04 2008
prev sibling parent reply superdan <super dan.org> writes:
Nick Sabalausky Wrote:

 "superdan" <super dan.org> wrote in message 
 news:g4kit6$nuq$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:g4k93l$1mh$1 digitalmars.com...
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
 news:g4ju5s$2dh0$1 digitalmars.com...
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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.

Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes. (I'd link to it, but it was on GotDotNet, which MS replaced with something else and didn't move this particular program over. So I'm attaching the lastest version I have (only about 11k), even though there are newer versions...somewhere.) Just check out how awesomely simple it makes this sample case: BEGIN CODE class WCArguments { public bool lines; public bool words; public bool chars; [Utilities.DefaultCommandLineArgument(Utilities.CommandLineArgumentType.MultipleUnique)] public string[] files; [Utilities.CommandLineArgument(Utilities.CommandLineArgumentType.AtMostOnce, ShortName = "num")] public int number; public string[] junk; } class WC { static void Main(string[] args) { WCArguments parsedArgs = new WCArguments(); if (!Utilities.Utility.ParseCommandLineArguments(args, parsedArgs)) { // error encountered in arguments. Display usage message System.Console.Write(Utilities.Utility.CommandLineArgumentsUsage(typeof(WCArguments))); } else { // insert application code here } } } END CODE The WCArguments class is itself the very definition of the program's command-line arguments. And attributes can be used to specify things like "DefaultCommandLineArgument", "MultipleUnique", "AtMostOnce", "ShortName", "Required", etc. Later versions include automatically-generated help screens. And the command-line syntax is the same ultra-clean-consistent-and-unambiguous commandline syntax that MS's command-line .NET tools use. D2 could probably come close to this with its compile-time reflection, but I don't think there'd be a comparably simple way to specify the things that this uses attributes for.

I just took a look at Phobos2's getopt. It's impressively code to this in functionality. But I still think this is much cleaner and more DRY ("drier"?)

in the words of the annoying chick in friends: oh....... my....... god! how could that dung be better than this? void main(string[] args) { bool lines = true, words = true, chars = true; string[] files; int number; getopt(args, "lines", &lines, "words", &words, "lines", &lines, "files", &files, "num", &number); ........ } this does everything that does /without/ adding a new class and redundant shit in square brackets. the fact that there could be multiple files is inferred from the type string[]. no new class, no attributes, no mess. shit man that c# stuff really blows. awesomely blows if you wish. how can anyone like that shit. to say nothing about the no-good generated help string that always is too short and uninformative to help shit. p.s. look! i wrote an entire post and no fuck! fuck me but this is weird. oops i fucked up again. :)

The getopt version forces you to list each variable three times. Once for the variable itself, once more to tell getopt what it's called, and a third time to tell getopt where it is. That's highly redundant. They're only listed once for the C# version.

narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say; bool showControlChars; getopt(args, "show-control-chars", &showControlChars); i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins? second, yarp i do define the var and then specify it in the getopt thing. but that's a good thing, gives me freedom. i can put it locally, or at module level, or in another object. but in c# it's always a member of a new type. shit. i have to define a freakin' *type*. that's useless baggage. why do i have to define a type to parse my command line shit. thanks but i'll use getopt.
  (The getopt version could probably be 
 changed to extract the name from the variable using templates and traits 
 though, and it could probably eliminate the rest of that redundancy by 
 sticking the vars into a class or stuct, but then it would lose the ability 
 to let you specify options for each var. Attributes would bring that ability 
 back without creating reduncancy).

run ls --help. you'll see there are 18 options with dashes in'em and 23 without. that's like 40/60. but then maybe some-option-x could be converted automatically to someOptionX by a template. heh we have an enhancement idea right there.
 Regarding the C# version:
 - Sticking the variable declarations inside a class is trivial.

yarp but i have to have a class in the first place.
 - All of the stuff in square brackets (attributes) are optional.
 (If you do specify any attributes, then the AttributeType is required, 
 however I was able to remove that restriction in about two minutes by adding 
 two trivial constructors.)

two minutes for command line shit is two minutes too many. that's the problem. command line is easy shit. should be a !brainer. everybody doing command line shit asks me to waste time with their crappy api. getopt in phobos is the first ever to ask me to be done with it in seconds and move on. i think it makes it look so simple people don't see what a work of art it is.
 - You can specify a custom help string for each element.

guess this could be improved in getopt: uint shits; getopt(args, "shits number of shits given for this run", &shits); so then the space separates the option from the help string.
 - The fact that there could be multiple files *IS* inferred by using an 
 array of strings. (At least if you don't use any attributes, that is. But 
 that can be fixed fairly easily too.)

hum. so then why would the attributes be needed in the first place.
 If anyone's interested, I found a link:
 http://www.codeplex.com/CommandLineArguments

sorry won't read. :)
Jul 04 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
 "superdan" <super dan.org> wrote in message 
news:g4lcjp$2dg9$1 digitalmars.com...
 Nick Sabalausky Wrote:
 The getopt version forces you to list each variable three times. Once for
 the variable itself, once more to tell getopt what it's called, and a 
 third
 time to tell getopt where it is. That's highly redundant. They're only
 listed once for the C# version.

narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say; bool showControlChars; getopt(args, "show-control-chars", &showControlChars); i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins?

The C# one could be easily modified to use a dash-based convention. Flip a switch, it's dash-based, flip it back, it's camel-cased. If for some bizarre reason you wanted an inconsistent style, that could be done too - and you'd only have to specify it for the deviating cases. Obviously that can be done in D, but I'm saying that the C# approach is perfectly capable of the same thing as well. But at this point you're really just splitting hairs anyway. My main point was simply that attributes allow for fewer tradeoffs between DRY-ness and power. Command line parsers are good illustrative examples of that. Although, as Lutger pointed out, D's vastly superior template system does help compensate for the lack of attributes.
 second, yarp i do define the var and then specify it in the getopt thing. 
 but that's a good thing, gives me freedom. i can put it locally, or at 
 module level, or in another object. but in c# it's always a member of a 
 new type. shit. i have to define a freakin' *type*. that's useless 
 baggage. why do i have to define a type to parse my command line shit. 
 thanks but i'll use getopt.

Tossing related variables all over the place just because you don't feel like making one extra class smacks of laziness. Sure, that can work fine for trivial programs, but the first time you work on anything substantial (tens of thousands of lines of code), you'll quickly see it blow up in your face. Running away from modularization is just bad design.
 (The getopt version could probably be
 changed to extract the name from the variable using templates and traits
 though, and it could probably eliminate the rest of that redundancy by
 sticking the vars into a class or stuct, but then it would lose the 
 ability
 to let you specify options for each var. Attributes would bring that 
 ability
 back without creating reduncancy).

run ls --help. you'll see there are 18 options with dashes in'em and 23 without. that's like 40/60. but then maybe some-option-x could be converted automatically to someOptionX by a template. heh we have an enhancement idea right there.
 Regarding the C# version:
 - Sticking the variable declarations inside a class is trivial.

yarp but i have to have a class in the first place.

You're already declaring the variables you need in the first place. May as well just put them in the same place (basic good design anyway), and stick "class xx {}" around it. Takes all of about ten seconds. And if you're too impatient to take few extra seconds up-front, or even a few extra minutes (development time, not runtime, of course), then you're in the wrong field.
 - All of the stuff in square brackets (attributes) are optional.
 (If you do specify any attributes, then the AttributeType is required,
 however I was able to remove that restriction in about two minutes by 
 adding
 two trivial constructors.)

two minutes for command line shit is two minutes too many. that's the problem. command line is easy shit. should be a !brainer. everybody doing command line shit asks me to waste time with their crappy api. getopt in phobos is the first ever to ask me to be done with it in seconds and move on. i think it makes it look so simple people don't see what a work of art it is.

A lot of people here do consider it a work of art. I don't though, because it creates a bunch of redundancies. As I've pointed out though, I'm not saying those redundancies couldn't be eliminated. If and when that does happen, I'd certainly praise it for being slick enough to pull off the power and DRY-ness of the attribute-based approach without actually using attributes. However, whether I would end up considering templates or attributes to necessarily be a better fit for the particular problem, I really can't say.
 - You can specify a custom help string for each element.

guess this could be improved in getopt: uint shits; getopt(args, "shits number of shits given for this run", &shits); so then the space separates the option from the help string.

I wasn't saying getopt couldn't do that. I was responding to this: "...the no-good generated help string that always is too short and uninformative to help shit." If my response wasn't relevant to that statement, then it's because your original post wasn't very clear. Lots of whining and cussing, not much content or coherency.
 - The fact that there could be multiple files *IS* inferred by using an
 array of strings. (At least if you don't use any attributes, that is. But
 that can be fixed fairly easily too.)

hum. so then why would the attributes be needed in the first place.

1. For all of the other attribute options besides that one. 2. In this particular case, the important thing is not whether or not it takes multiple inputs. The important thing is the distinction between "Multiple" and "MultipleUnique". Ie, whether or not ["fileA", "fileB", "fileA"] is allowed.
 If anyone's interested, I found a link:
 http://www.codeplex.com/CommandLineArguments

sorry won't read. :)

That wasn't directed at you. I had a feeling you wouldn't be interested ;)
Jul 04 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
superdan wrote:
 narp. getopt is better for 2 reasons. first, if i want to have an option with
a dash in it, with getopt you say;
 
 bool showControlChars;
 getopt(args, "show-control-chars", &showControlChars);
 
 i and you and anyone who's used getopt once knows how to do that. but i have
no idea how to do that in c#. there may be some shitty attribute to do so but i
have to go check the manual. who wins?

So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?
Jul 04 2008
parent reply superdan <super dan.org> writes:
Robert Fraser Wrote:

 superdan wrote:
 narp. getopt is better for 2 reasons. first, if i want to have an option with
a dash in it, with getopt you say;
 
 bool showControlChars;
 getopt(args, "show-control-chars", &showControlChars);
 
 i and you and anyone who's used getopt once knows how to do that. but i have
no idea how to do that in c#. there may be some shitty attribute to do so but i
have to go check the manual. who wins?

So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?

narp you are confused. there must be some option in the c# attributes that tells how to do conversion from dashes to non-dashes. my point was that that needs to be looked up whether or not you are versed in c# proper. with std.getopt you don't need to look that up because the string is distinct from the variable it binds to. nice try though. one attempt at irony missed, two to go.
Jul 04 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:g4mmed$a2u$1 digitalmars.com...
 Robert Fraser Wrote:

 superdan wrote:
 narp. getopt is better for 2 reasons. first, if i want to have an 
 option with a dash in it, with getopt you say;

 bool showControlChars;
 getopt(args, "show-control-chars", &showControlChars);

 i and you and anyone who's used getopt once knows how to do that. but i 
 have no idea how to do that in c#. there may be some shitty attribute 
 to do so but i have to go check the manual. who wins?

So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?

narp you are confused. there must be some option in the c# attributes that tells how to do conversion from dashes to non-dashes. my point was that that needs to be looked up whether or not you are versed in c# proper. with std.getopt you don't need to look that up because the string is distinct from the variable it binds to.

getopt has plenty of options that need to be looked up.
 nice try though. one attempt at irony missed, two to go.

Consider yourself extremely lucky any of us have been trying to help you after putting up with your attitude. I haven't seen one post from you that didn't include unproductive and clearly deliberate sarcasm or insults. I know this newsgroup operates on an "assume good faith" approach, but even that only goes so far. Keep it up and even the most laid-back people's patience will wear thin. If this were like most forums I've been on you would have already been banned by now for being generally disruptive.
Jul 04 2008
next sibling parent reply Dee Girl <deegirl noreply.com> writes:
Nick Sabalausky Wrote:

 "superdan" <super dan.org> wrote in message 
 news:g4mmed$a2u$1 digitalmars.com...
 Robert Fraser Wrote:

 superdan wrote:
 narp. getopt is better for 2 reasons. first, if i want to have an 
 option with a dash in it, with getopt you say;

 bool showControlChars;
 getopt(args, "show-control-chars", &showControlChars);

 i and you and anyone who's used getopt once knows how to do that. but i 
 have no idea how to do that in c#. there may be some shitty attribute 
 to do so but i have to go check the manual. who wins?

So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?

narp you are confused. there must be some option in the c# attributes that tells how to do conversion from dashes to non-dashes. my point was that that needs to be looked up whether or not you are versed in c# proper. with std.getopt you don't need to look that up because the string is distinct from the variable it binds to.

getopt has plenty of options that need to be looked up.

Hello Nick. Sorry maybe I came in thread late. I disagree, std.getopt has 7 options and a few syntax. many options are "no" for other options. If I understand what super dan write, I think he has a good points. There is repeat a little but it is small price for simplicity of library. And I disagree when you said that just wrap class {} around variables is not important. it is very important. more types should not add without necessity. I have some variable in main() that I parse and maybe few globals. Why put they all in a class? It is not wanted complexity not justified. Also the modular part is not good argument. Code to handle command line is unique, never called from the app. Only once. Should be there in line. Design for modular there is not justified. I think even is mistake. Parse arguments is simple problem and should have simple solution. std.getopt is simple solution. (only one function!) All other are complicated. It means they did not see how simple problem is. Thank you, Dee Girl
Jul 04 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Dee Girl wrote:
 more types should not add without necessity.

It's a matter of style. If you ever use Smalltalk, adding types is the preferred way to represent any piece of data that associates logic.
Jul 05 2008
prev sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Sat, 05 Jul 2008 06:05:39 +0100, Dee Girl <deegirl noreply.com> wrote:
 Also the modular part is not good argument. Code to handle command line  
 is unique, never called from the app. Only once. Should be there in  
 line. Design for modular there is not justified. I think even is  
 mistake. Parse arguments is simple problem and should have simple  
 solution. std.getopt is simple solution. (only one function!) All other  
 are complicated. It means they did not see how simple problem is. Thank  
 you, Dee Girl

Code to handle *a* command line is not always unique. argv is only one possible source. Imagine you are implementing a shell with several builtin commands. These commands will have options that need to be parsed. Still if I had to vote and it was based purely on the discussions so far (ignoring the rudeness) I would go for getopt. Fortunately getopt in D is nothing like the gnarly beast that getopt is in C. I don't think the three items required by getopt are redundant. They provide different information. The variable declaration gives the type. You could only avoid this by making arguments a special type like stringArg: public Arg which tends to overcomplicate things. As has already been pointed out there is not necessarily a one-to-one mapping between the variable name and the option name. Especially if you have different conventions to conform to for your user interface and your code. Assuming your users always have the same requirements as programmers is a bad thing. That said providing a default mapping and a way to override it does make sense. None of the discussion so far has provided a decent use case for why we need C# style attributes or even a definition of them for those in the group less familiar with them. If there is one I doubt its going to come from the command line. Regards, Bruce.
Jul 05 2008
prev sibling parent superdan <super dan.org> writes:
Nick Sabalausky Wrote:

 Consider yourself extremely lucky any of us have been trying to help you 
 after putting up with your attitude. I haven't seen one post from you that 
 didn't include unproductive and clearly deliberate sarcasm or insults. I 
 know this newsgroup operates on an "assume good faith" approach, but even 
 that only goes so far. Keep it up and even the most laid-back people's 
 patience will wear thin. If this were like most forums I've been on you 
 would have already been banned by now for being generally disruptive.

hey nick. been lookin' over the past messages and thinking for a bit. i need to apologize for layin' it too thick. my problem was i delurked in a fuckshat-up mood due to some attitudes that've been goin' around this group for a while. some around here feel they can demand shit solely because they use d. there's a foul sense of democracy when everybody who's nobody has a proposal and self-righteously demands for an answer. also afaict walter is very connected with this group and listens. yarp he has no time to answer the good suggestions but you know he's listenin' and you can see that with each release. plus it's like brain and mouth add to a constant sum around here. a hundred years from now sociologists will crack their skulls to figure this phenomenon on digitalmars.d. the less they know the more sure they are they know and the more they ask, boggles my mind. and makes me fuckshit. the problem is my fuckshat-up mood carried without reason to normal discussions like getopt. looking back i'm amazed some people (such as yourself) could actually come forth and establish communication. says a lot about'em. and guess what. they tend to be the more knowledgeable too.
Jul 05 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:g4k93l$1mh$1 digitalmars.com...
 Command-line parsing is one of the big reasons I really wish D had C#/Java 
 style attributes. I came across this one particular C# command-line parser 
 (written by a Peter Hallam) a few years ago and absolutely fell in love 
 with it, and by extention, attributes.

After all the responses, I'm now sufficiently convinced that there aren't any obvious cases where C#/Java-style attributes would allow for functionality that can't be achieved with D templates. However, I still think C#/Java-style attributes should be added to D for the following reasons: 1. Part of D's design philosophy (and one of the main reasons I've been so drawn to D) is that it gives the programmer all the tools they may need and leaves it up to the programmer to use whatever they feel is the best fit for the task at hand. We have all the standard OO features, but unlike C#/Java, you're not required to fit your designs into an OO model if you feel a procedural approach is more appropriate for what you're doing. We have garbage collection - but you can still manage memory manually if you need to or want to. Using getopt or the Tango equivalent, you're processing command line args procedurally - the structure of the command line arguments is defined by the way you call the appropriate function(s)/template(s) and the parameters you pass into those function(s)/template(s). Using the C# attribute approach, that's flipped around: you're defining the structure of the arguments, and that structure drives the parsing. Clearly, you can implement any command-line you want using either method. But if you're going to disallow the latter method just because you can get the same effect with the former method, then not only does that break an important part of D's design philosophy, but you may as well start throwing away things like "while", "for" and "foreach" as well. After all, any loop you can implement with those constructs can already be implemented with conditionals and gotos. So why do we include them? Because the programmer may decide they're a better fit for what they're trying to do. 2. Maybe it's just my inexperience with D templates, but it seems that any non-trivial template magic (ie anything beyond standard template functions and template classes) has a tendency to involve dynamically generating source code by pasting together various source code pieces and parts. Now that's fine. In fact, that makes D's templates extremely powerful and extremely useful. But it also makes that sort of template a very blunt, if not crude, instrument. In fact it very much resembles writing text-book-example PHP code or classic-style ASP. And there are good reasons people are moving from PHP to Ruby on Rails, and from classic ASP to ASP.NET. Sure, pasting snippets of source code together is very powerful, but it also tends to get rather messy. Of course, I'm not saying we should stop using fancy template trickery or other forms of automatic code generation. And I'm not saying any of those are any sorts of inherently bad things. But everything does have its pros and cons and if there's another way to achieve something you're after that doesn't use such a blunt tactic, then even if not everyone uses the alternative approach, having it that can only be a good thing.
Jul 06 2008
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:
 
 Clearly, you can implement any command-line you want using either method.
 But if you're going to disallow the latter method just because you can get
 the same effect with the former method, then not only does that break an
 important part of D's design philosophy, but you may as well start
 throwing away things like "while", "for" and "foreach" as well. After all,
 any loop you can implement with those constructs can already be
 implemented with conditionals and gotos. So why do we include them?
 Because the programmer may decide they're a better fit for what they're
 trying to do.

I'm not sure attributes alone are generic and generally useful enough to support the argument that they enable a specific programming style. But perhaps reflection / introspection is, and attributes as far as I understand them are part of C#'s reflective capabilities, which are way more powerful than what D has. However, the limited reflective power of D is at least partly intentional though it seems to be growing. I recall these motivations: - Lots of reflection bloats object code - D has and will have some more compile time reflection (templates, __traits, is-expressions, etc.) - In many cases, compile time reflection is a sufficient replacement for runtime reflection - In other cases reflective capabilities that are lacking can be built using compile time reflection
Jul 07 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:g4ss8s$1gqg$1 digitalmars.com...
 Nick Sabalausky wrote:

 Clearly, you can implement any command-line you want using either method.
 But if you're going to disallow the latter method just because you can 
 get
 the same effect with the former method, then not only does that break an
 important part of D's design philosophy, but you may as well start
 throwing away things like "while", "for" and "foreach" as well. After 
 all,
 any loop you can implement with those constructs can already be
 implemented with conditionals and gotos. So why do we include them?
 Because the programmer may decide they're a better fit for what they're
 trying to do.

I'm not sure attributes alone are generic and generally useful enough to support the argument that they enable a specific programming style.

I wasn't trying to say that attributes would be useful in all situations. Just that there are a lot of situations in which they would be useful enough to be a reasonable, athough not totally essential, alternative to templates. Obviously it's not going to change the way you iterate over an array or anything like that. But going back to the command-line parsing example, suppose that you *want* to design it in a way where you define the command-line "language" by a class and use that to drive the parsing - instead of the other way around. Currently, the only way to do that in D, without giving up the ability to use special options that don't have a class-definition-equivalent (such as required/optional) would involve a template mixin that dynamically generates the class. But as soon as you do that, you lose the ability to actually look at or edit your class definition in the source file in the same way the you would look at or edit any other class. On other words, there are situations, even though it's not all situations, where attributes would allow you to implement certain types of functionality that could otherwise only be achieved by hiding chunks of your code behind source-generating template mixin voodoo (which I currently find myself making enormous use of). Of course, one could counter that with, "But why not just use the source-generating template mixins?" - to which I could counter "Why would you want a while loop? Just use for. But why desire a for loop? Just use goto. Etc..." You don't *have* to. But some people have reasons why they prefer it.
 But
 perhaps reflection / introspection is, and attributes as far as I
 understand them are part of C#'s reflective capabilities, which are way
 more powerful than what D has.

I admit I'm uncertain whether proper attribute support would require run-time reflection, or if compile-time would be sufficient. Though I'm still for the addition of runtime reflection in either case (*in addition* to compile-time, of course... See explanation below).
 However, the limited reflective power of D is at least partly intentional
 though it seems to be growing. I recall these motivations:
 - Lots of reflection bloats object code
 - D has and will have some more compile time reflection (templates,
 __traits, is-expressions, etc.)
 - In many cases, compile time reflection is a sufficient replacement for
 runtime reflection
 - In other cases reflective capabilities that are lacking can be built
 using compile time reflection

D's compile-time approach to reflection has indeed impressed me because of the level of functionality it allows at such better performance than runtime reflection. As far as I'm aware, every other language that has reflection doesn't support any such compile-time version of it. In that respect, I'm more impressed with D's reflection than I am with say, C#'s reflection. However, now that we have that compile-time reflection in place, I see no design reason (there may very well be certain technical or syntactic hurdles for all I know) to not add run-time reflection. In fact, the way I see it, it would be against D philosophy not to (Give the programmer the tools they may need, and let them choose what's appropriate for their task).
Jul 07 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky Wrote:
 D's compile-time approach to reflection has indeed impressed me because of 
 the level of functionality it allows at such better performance than runtime 
 reflection. As far as I'm aware, every other language that has reflection 
 doesn't support any such compile-time version of it. In that respect, I'm 
 more impressed with D's reflection than I am with say, C#'s reflection.

http://thedailywtf.com/Comments/22-The-Offshore-Coordinator.aspx?CommentReplies=202585
Jul 07 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Nick Sabalausky wrote:
<snip>talk about attributes</snip>

IMO and I'm not an expert on this - attributes by themselves are pretty
much worthless. however, if you combine them with additional tools they
become a very powerful feature.
If you have AST macros and reflection (both compile/run -time) than it's
far superior to just templates.
examples of some things that can be accomplished with that tool set:
- DBC (instead of putting it in the language [and not implementing it])
- Active objects and concurrency.
- Aspect oriented programming
- etc...
Jul 07 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jarrett Billingsley (kb3ctd2 yahoo.com)'s article
 "Matt" <no-one none.nowhere.com> wrote in message
 news:g4jqum$269v$1 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

However, there is one in Tango.

Tango actually has two right now. tango.util.ArgParser is the original one, which uses callbacks to process arguments. There's also a newer one at tango.util.Arguments which is a bit simple to use. It basically just exposes the arguments via opIndex, much like an AA. Sean
Jul 04 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Matt wrote:
 Is there an established library in D for handling command-line arguments?

http://www.digitalmars.com/d/2.0/phobos/std_getopt.html
Jul 03 2008
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Matt wrote:
 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 wrote one of these a while back, which is based on Python's optparse library. I wrote it to work in both Phobos and Tango, but I haven't tested it against any recent versions of Tango. It handles your second and third bullet points. It is relatively stupid about the first one. (It relies on the shell to quote things, etc.) Two source files: http://dsource.org/projects/pyd/browser/misc/optimpl.d http://dsource.org/projects/pyd/browser/misc/optparse.d Example for Phobos: http://dsource.org/projects/pyd/browser/misc/opttest.d Example for Tango: http://dsource.org/projects/pyd/browser/misc/opttest_tango.d Documentation: http://dsource.org/projects/pyd/browser/misc/optparse.html If you've ever used Python's optparse, the API should be at least a little familiar. Otherwise, well, it's not that complicated. :-) The examples should give you a sense of what it looks like. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jul 04 2008