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 :)


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


 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.

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 :)


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


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








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.


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:








 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.


 
 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.


  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.


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.




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


begin 666 commandlineparser.zip

M?Z )F^$1F R/P6"")D1?I8.):P<''ZL#H^$Y? `'MWK7P]B""QHVO_9ZW'&4

M)YD3QX-3M/S,*4*K3816+N3^C\?Q)>0\[5_[8M_WNZ-6UY .B,IKS,6-L"0W
MLYQEM'\>_J]B[7NMOW5NL9S.\T&H0\.: S_%XVN_E8MK6KF0II-][;3/?-Z9
M)/R=V!-02P,$% ```` `R$V^,$-5J%VM`P``> D```\```!!<W-E;6)L>4EN
M9F\N8W.-5EMOU#H0? :)_S"JA-A6/>%P'GN.C 1;BBI$5;$%A" /CC/9N$WL
MR)==\N^9<2Y. "VLM-K$'G_S?7/S!J?T%C:=\]AD[[&L47IE]+]/'B]W O:J

MD$9[:^H:"_"5-6%;T2]"24MFSTXCG$,/I 3AO55Y\. R6%=";Y&-':8-V(DZ

M/D<GK6K9QV&CM=&EV 8K?F?6M$)WAPVNK2F"] \AM)U5V^H!DQLK"FR$O7\`
M)=0^V%[THT>S]'Y$ZTC!/+! 3_- <F:=<MY1XI8II:= AT2=39#Q\T[<$<J 

M2T&:>7>"(5'%PI/K&>0=Q+:(QL].GI%R<)79:\B1A)*R7\9T4+$Z>I']G9W$
MR$]$+S61*=!R^3JUU<S+3A&-+)O ?!("]]B1,1'!C B7\6 D%/'>*6F-,Z6'


M]%OLKD G6 X'3X(Q3)7P4 EFBERYS L>._04 =>V:\EV&&81K_]0K^T4)V6U
MWEP? QFRT A9*8T9^[M0]=)?20M]`&(X!'E+B#V
MAG+CJQ]#DI!G/=9:0R,YUJ>1,EAW-C-;O1A\)A]2<-UR:^HI)*3W-(9MGL5L
MCO//3SB%P3XQ^(V:/TI)TOKM?BMRC\ 1</I$Y^D$N5WDRIN1&F/WC%(D%QTD
M+0I/T1RA3J<V#T/Y.IWA-X35A J6`L4"CB%X52O?S75^JG":'D/'3Z#QI39R
MZ)I%)GD>!)H;^;R>+-9DN\.A4SE3=W31`EV.+=V/A;+T9FPWU(^:5\[3Z\'X

MPVF>C: ),DT%'HEI!/YX9'649;>W_&TZ; BG[WD<IF2>4Z0ZV/03 UC'ZZ78


M0 R>8_!_T- N-5W;4 CM6C+86\  [M3XP/= 4 JAY+]'YR3 $+ 'G_0]A X2
MTA[ZHRC%][9IFX21I* C<#E

M!8<UL*8\QJRV_; >1B;TNPI%C>S +P<//^;Z),JV >T.D/?R;)1YE.HT?W6 


M6)V)I(DL.YWS9$5NW5S:3..FC9/3AQP_T")DLX<B59)*[";^]^XNKKP#E-)S
MJH=$(H'%WK"[V 7 )-CP?!NL./M81'%41#S_
MHOYH_C(*;I,T+Z)5WO3Z/5_'?%5$:=+T]D4:R[>-G=^\:WKZ =\7\%R\.3DY

M6^!.RO ^O8Z#V_P:OXH'V]U-'*T83W8;]D) >PO +B2L#P

MP0,/R^"B-8L*[)JD!=MF/ >4V)<[GB FU(AN)%Q^WLOQ\?N2G=Z?/ILY$?4N
MB1_8YR". (H$Q?"O74*"!O2+.W:YBXMH&_,*!B]WVYAX 5UW/!>T` W0'.$$


M1GPP."N5TAHY8S>[  45K837VS0K>*CUT)5;351?%)= 6MY!8TGUJ25$)^I?
M=Q [HVEA"Z8-WQ),0AZ "L*AAZ$9+ &TE]K+TIK0Z7<<Y$4)H& .R$2K.Y:N
M5KLL9U$%KSC*"P>&O078[Q "!QS_&24Y6VK5V4MA!BC+EF>;J"C($ NRV$9I
M<1&!QQ$:%.HY7P)7L "K8)=SK6L`S]8T![8H%BBC8)C"ODE+(17K4?S7Z5PN
MXCC]DBO?4O4IRLS.K0Y%$:SNA&4/BB*+ &Z.5(" B `D)>Q]#J"0XT UD!N:
M_H%0G)"#FTT
MM].]V1E3W[W<GQ<WZS15GD/S8,,PH%F.D)6C<W8EYS,Q46K0ZHZO? :P4I7"
M%$9*RU-N#H,0-#F


M$(D<)#H
M6P!$-/2)%$?<1Z+8_S "190=Y/F2W^QNYQ=YSK-B<D0T5&B>+B2EAL)VF9LV
M72*OLV6;19_!KRODC6:U-L$Q6EITF%75_+%E4=BQT"H'9R;P,2(RW<<G8P9&




MC0HR8Z#SYH$%84CI$(=Y J"+M(6C589)[C;)[ )R"+"B!=65_55*`13C9QY2
M< 3!N6BL 1J)^0G$T 0UZD/P4ERF ]D2UNM$62^Y8A=R58(WG1O1?[,FGVRT

MZ9*!"%9W8"M6!<\D9!I*`GJKON:XI->Q1_S0-&/,`#DL< $R\'1':\JY$J/=
M1O&=UG  B_1S%!(G`S,?$9\F`L*44Q(&%7D-*!5"80*;31F [(QQHXXJ[1$9
M"3'K<$J:6=B<#F FG:NAZ==J#AHT*MF 1D?IM 859M3'H[W(./FS "7\2\=*
MFKND&FM^3(&XLLWSZ!SU$WF(NBQM!!H5,9#V7EV 9<HC0UAEFZ.GEW28N=_R
M57!P0 ZO$?N9L*SO)0),8=*SHLU4^Z7NL6AH9I1DB0(1'N MI+PFTZ[FE\%6
M=OA+D-\5P4W,:QU*OY!+:'O8A$*K-\DZ5:GVI)GN^9]Y06WSR533:N M?W 1
M,SD25NQ-?E4`A!5[\H3I1Y!<+C K7'KX- *N!+&$7ANA_NF,^ +];<D`=Q/?
MT'"&.W7$3<_(*<"4"#LB

MV%H.-ZE0UC\?R M1:]K.7T D%H#C_RM_F.B(0ZU.-1NZ9OZG6K=K4 /U<-$\


MGU0]:&L (".=3]?&-8&;%YW0N[Z D#G


M"ZQRE1.S!RD\E7HS+/S.1^<.X;05/[>V%^+*SU666E<A14D3DBV E&I4$QWE
M/02E2EH0UBJ)P9Q 7&>25#N>;Y6A ' 7A"+3L103H6$>(&1EZ_I-J3+,55V2


MQ+O)LYF%P9(=/V-_8%5V'[-G[,PT._8<^*+N7-H$+3JH<9_"N,ME%1TIM &"
MDY\*6FQ9-9Z.$7,UL&]1U6= 1XDN.U+X5'M[C22#I+\#F77QUQC^^^G^?/A%
M$.]5R<?^<;M;V"$F6YJ0<UH/L 1RUPX*3["$`NXO\ Z7KCWLHA^,<0;DI/;C
MZT$40F/T;<DP,)Y?\>)'+(U-RJHR*[F\_1"_`0?V\Z+/Q/]Q?.9B"<%Z)X"9
M$0CN3W6E^"V_?QW%7'>=-)EQ"&$A,5\=9>HQ3#VJJ #SXFX/^U0V^JQ_BC0F
M:(X.-6=*JM4TE-&UX#MHV4&FQZ]QWBOY>W;?,S$E`F=-R>%7$P/3][!^*.UG

M%5(W1 BS-O.JN211J:7BQ2;*L3:H]Q<;QCBDD(9DCVQ+ C[J=91$^=VDA'%-
ME?<P=CTH-$'RQZEQ>AVYSB^GF7:!E<L,JZBPPH ?X%=PJW?P`*8K2(*(4C1O
M22/D#Y >NW>8FN7=3[A+IG/K4R^_KPC0GW91' (%-^)_43PHOYLTV=_*$[D>
M3.-0!+6RQ_ZZVNY%S&!LJ="?ET;OQQD^NNO%= LRG(Q(!J/IPJDUH*U3[FU=
MH) H=\'3-S'!?E2_.XI05I\EDYE X/+4/WU0I?'L.< Y'WE46)2_;T5L=RC,

M]+5&2=7CBJTK_?%>5YE;(V^7MH<EUM2D+5>\]X_Q$291.NUOBQ]JJU*A#H%S



MXH&BHG-Y:E^A"UX.O!1/]HCN#QFT-8GAN6MXUH1S;[Q6'?'<=30'UCJIJ5BI
M:. ?4A&.0QSN4LZ&3VM)&X/TLE+"`UJ0B)^5-6X=I\N N)M?!O>3'V;LAU-V


M\(S&FDX)W(?T%:B? [Y5?JX"*BJ^NE]Q467C_<OTSK(Y+:SAK$6 >U]2H+QE


M_CDIFJI2^L\0"0QC<7?=QHW8/T=;[%R(2S=$NQ; 6$J&R/J?V/H*6U->[1,1
M<#U %24H?PH[8 X1LP`QOV/'J/#B!$>*16?(;Y+JMT>5A 11//W=^#L0HIE8
M'N\(QOLI&>^QX'$9N#U:IS,H4;+C!^)_"&?K+3/3V X:^?.W04X__;07WV!K



MTQS;N7]'S!^5U3SJCB_ !&FFMN"C(T$ZYV HLI9P;3VMQGI]?#HTH!>7 \F=
M>+OBW?I]D-QR'>;W!_G 2V_A9-VK=Z];D &2$1[5&I=UP\?D)HCQ]&,(OFDT




M;W)S&IAZ"Y4B&/A[VGXBPVJIZE0V&DA'OPL><,P"Z>ZXZ(BN 724GH?J1NL&
M4;8SQ\ 7D6I Q;[<;R%_7KY#S4<&;1#U

MG"IO_='MALX[AW/KS8%,]=*C]E/S\U:OTGJ,E=M.H1=^AU-K'2%W DP0/5'7
M"H^ ;?7O[K=&ZPD]R(JZ#T=OU7'!5F(Y3VAS4=L>`/?K"'33*)?^$]HV>EK?
MX_+.14?;L+G'W(3T2G44[.B_3L&Y/E<YNF^F1HDGI1?VTF'1=S;<)AI,C; 5
M4M]<RD8OZA>.T&TKZH(X;*XO%!GUCR>\&(YDCPP#B1?B:J] BQ,/KY40=TG7
M4> ?J<5/2'O:\6EV<-/>`4OZ T)IP,":Q%,'3"9'59 6`'T<QFMGJKT966YR

M_1AL59Y[X'JQ6?6FQ08]NQ+6UZ<(9N I*]N1]&M+H%RV;1AGX^>0)CD?ST="
M /:]$KY;` <B< ((>(POQ.^1J;&+O4.TPCI1KN]<5_I LI2TTF[!?2OD: 29


M8Z+P'5!X[YQLQ!(EW0&,./1NYR8VZ(N,\)?/ED=XY(;44"<M<=I[\QG,`3]C
M*HP.!4%:OWMM2OW*Y5)P]8?Z,NM,/,+O"Z\L=X.U_U,0?C<[3]9+_9F(0)0`



M52W<S] X$!*M^T6%3T=/1_MO^B"N]1\<\>.9P^X`S;L*3<<'I,GUV,=!B!J 

MA/8BO_[8;*'P-NXG)Z)CZ2RZ\[ .FY]J+9ICF$[E4:P?NF^Z!1^'O\S 7,._


M'[!XHZ'KM6X_%)J*" .90)BHA&W_70LV&I62FN?PO7\CAKG]L1E672)J^^?2



MK]1WJ+AOH%" :%FE%&C+1 LBM-T%-\8YI%Z=.+(=.C;MW6<G`0HD$*:U4U4K
M%XG]'9_O_#DG,>^)"!&U9> 0UN?L.V!Y?GAPI(;9M*^M05\])"-9'LX"./I\

ME?IEJ7UR7#VMEX]/JXWR\5F[7CLN-UN-5J5<JE8:M=^)_/ER&_,B)-1))A:3

MX',(9IZ'?(<JL0!Q`7R+3(\3E_A(,JZ471*:I:,%$Q12V:0$?&EC3 *ID5_B
MVVR!Z^%-MX]<Z*(9"R.1*TZ<;/P0<1=D'$.-[K2KI50T13.;N)$C)X *2 'U


MQGM3X)-(E1/?[-(3&Q;R*+>UM(HOK&?29K"5?Y6DD,B7(K*]?7%W]6DXL)KM

M_QU;]P))//(3MKEPF:A])!\U<DS\4<1_E $? $N$!*ZBU61>QU>W+%CHR!3R


MEI?PR&H4<H&OB;\(E&&,LJZ'SFVK]V"/; CF3+")-&[;P]$E5RJ>&7\:34]4

ML[A2$<OI]7;=U ?;1CFI$XR&#JQ.+_%9)P?51J^W])LCXF!AF7R7Z-9>'98Y

M]47V#FC>24*)G/TWIF9Q64_+N7GAQ4_Q'P#U


M% L!KLE=-]_9I+MG-O&,&TL%09MSE6CU`1G>M5N16W&?//32I/ZJ(O>6B[P.
M;(,$$+ED)DIA`1ID! G%(KJ-.IUHCUVG57+!F=_XOYYI"5XY +EEG69F*.E<
M0(\D%<3<T5ZQH,) 2/%^IF0J2RHI _Q,'7D9$]!?H$_6I5 JA I?I\C/4#S1

M''#M[J_T*LAS+!Z'GD)MFTK9O=2B*0B 8<N=[("K2:\F/=6D<7<S=-W&+K _
MGN,)%J#K.FX4?S/UU7)5`P,P#J


MDO ="">7""F", X[R)\N.\PL<]F]PJOI4EK2PK+%^=U7%): .Z W>)[V]SSO
MVV>:2Z'$IK;>J6H(LU9U4U!AK01K:BJXA2F#B86%+(D^`U*U8N B9!HO4GQ 

M ;0G_XANKBI-;[V='_HA1IGGS()PZ 2S:.K<9^'<F29IE/I3-/.C^=XVC8P7

M[8GN:?T5&! %VM'9 Z2SY*Y9"A7P`GA.01URA:K[X"LPP_[GG-%E2W,/ [D+

M6C>]UX"S*(HG?AGF3S&-7U!+`P04````" "J4;XP/7=C3Y0!``"J`P``!P``


M+S.*"&;W=[X()5JF73[(J<+2Z R6SADPVB*-S_T;Y_-+_FRM_,$_G[(VFC52
M^H K%0S?N[)4-G\2T$/;)"9=B+[7%:83J=25P:G57P$'BY.NQ%[;8KZ E38[
MIC)CI_'_.M[QQ!&_V R'\+9VGI]5B7 +-[+6FX; 5=M=6P;Q+=&/C\Y(Z2/8
M3_&/1FVD%08R9YR_$)"22AEDQO%.HBC201O!5BSYWT[G,%':)L=FRA<TV"<U
MN?O3U5>P/6$NWR2C6-QT \E '(OT"I+KN*7]K4Y?F_K.RF)QTWO8P1^T1(YD
MXAF-`+UW'M!F+EA&^4%EC: .8"D\:*J,JB&0*A!*I,:>HKS5Q%B*?I:<P73F
M-6-RSO 2V6F#EK

M>'3M6-V/TT80?X^4_V&;/I!3\W'0/E24(HZC"*1257 (58B'C3V)MZR][NXZ
MN;3E?^]O9OV1D(,6J>H+]4EG>W?F-]\SZURZLM15KGXT%:D+OVE*JJ+Z6?M 
M?CR:?^0:C\:CBR86SM]5-47RA;8/2I-Y%]PZ+C)7, 4CF6JCLE:.93FZE1-4
M=$ICKPK.8KFNK<ET-*Y2)F"#F?!<>[>R5"[4>'158,.:E==^KPH`6 )(01UI

M/XB?J9S60&%0JT-0N\*!9&W(Y $*U)X") MFKJ/& XYJ[QH/N8>F[G3R!' R
M,EM*J Z:.]'K2/.%NBJH4IFV%F OH[$F& J+]+1?2/S:T')D+SJPZ1D$B<6"
MZ5:_4A;5SL2BUQ. HL"IS!]T5B3[6E\EPUL_M $[C7**&XDS$1MF[% ">S6'

M;H<$$0/"7>:;JQ ]EOC)5)%O37M?.6?Y3E53\EU[K_<=EEZY;7($HSQV7M&U



MOQ'%>>_=H?A.*LAT!/76F5P]TZ::=GQL4#A+1$R;KD/-D_DYWH/Z7E6T.]R<
MGGTW,)FUFG[Q*27)LF<'^&=G*J'UV S7<JG(>\Z;2J).GCA#AH LU",3:JOW
MB(S>D"HI\/T8Y<4^1/33R]1W%Z^\B30]5?DF;5\RVI0SV*VG PN ]*$/W V/
M9 -]Q!PHC^J+A[U?\D<5,.T$\%T;V1=.[;O$E"Z8.K/N,5)+&]+R9 1%E\H&
MKL:[]/N6W$DMK+3G9))Z3[)WV8*N22T3^3)M KQ[!$??4KS;>%U""6B6IW <

M>/W5G_,WZD-7P%B7+E."O&7C>OP$MEW+QN7Z"6R9L'5.O9<J]/[?LJT3VX-[
MS ?RCUS/N:MB.-<.J2=!EG9:.M]US) "J2,Z<4 T*<:](AWV"_7$[6A+?L;Y
MQ_W9[OMN[4J3IOVD57["N+(R'AUU5AG?&%91&QO2*K4=%L;**%KQT*JB1WWF
M;9/-FA!=R5D1X915$SN X1V)9+*BX^P``5;HK>&3A_:I,]]0VA<=2MM]YAU,
M2(Z6 3I3U %0'F'^;XU!`\(0X;16>9/JC^"_1[36C8W_2(YP!_8?.Q_^:+W(
M4B:+CNI**KQGQHOPP3W,4]D]_J79?3HS91(L4N?H M)6T%"LU$82<OZCZ?7Z


M:^.("04KW&=//5W+_,E==2MV\^?PH,%XC96O2GEM\SX=FCB>-CAN?%N3(^4T

MPX!Z`AQ=8OE+:%+6QF+M$<:H=37_RO"L^]$`N[X&0/?W'&II..4G)S/EY.>'
MV^?+\SO+.^?G=]33"I6,+YV61?9N?Y/V'C8;]=  Q<YO+\^_Y;6OU4,G:]Q)
M'N!?9IL\.3_\!5!+`P04````" "=64(MUNT64Y "```X" ``" ```%5T:6QI
M='DN8W/E54UKVT 0O0?R'P9?:H&1?T": &E*+Z6$Q*&'IH>U-+*WK'?%[JR-
M"?GOG=V5(JGQ5P^%0'60Q&KGS9LW;U9:K-'5HD!X)*DD2727%\^7%\"7=U(O
MX6'G"-=7:2G=I],I?'1^O19V=],MS:!$A4M!R*%8 M2 UAH+%FMCB<'R7OQT




MC%BVA2=.3"8H2=8HJ)E*$'.!*[&1QMLS%(CK'"C6$*;D>B1:[J.;V&Y1D!<*
M7I=SAHG[CX&4Z' 2!$FC&QB+SJLP'9$EEF<`6B1OM;L!LAY!5J -8!)PBZQ 

M)$.'VP><A/'YXP`8VN&[E80!*LMZ,_%/3?H_>ZX/:)N.-& ]?*B,39C)D._(



M;NX</S>I]IDY=F<\#Q7V*S]Y_HZ/.[&/Q4>O5RK+\IAKZ*3F\?(;4$L!`A0`
M% ```` `R$V^,$Z*RI[!````- 0```<```````````` `````````$%P<"YI

M````07-S96UB;'E);F9O+F-S4$L!`A0`% ```` `R$V^,)A2F5K3````8 $`
M``D```````````` ````P 0``$-L87-S,2YC<U!+`0(4`!0````(`/%P*"[9

M96YT<RYC<U!+`0(4`!0````(`-Q-OC!?7>'F5 ,``$$0```8````````````
M( ```&P9``!C;VUM86YD;&EN97!A<G-E<BYC<W!R;VI02P$"% `4````" `K
M4[XP_[=WX%0!``#L! ``'0```````````" ```#X' ``8V]M;6%N9&QI;F5P

M%0```````````" ```"'' ``8V]M;6%N9&QI;F5P87)S97(N<VQN4$L!`A0`
M% ```` `JE&^,#UW8T^4`0``J ,```<```````````` ````#B ``&UA:6XN
M8W-02P$"% `4````" #E

M````````( ```&HG``!5=&EL:71Y+F-S4$L%! `````*``H`9P(``"HJ````
!````
`
end
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.




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




 (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

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 


 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. 

 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 

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


- 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

 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

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 


 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. 

 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 



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

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

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.



 - 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



 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 

 do so but i have to go check the manual. who wins?



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 

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 

 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.



 - 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

have to go check the manual. who wins?



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

have to go check the manual. who wins?


 

 so getopt is better"?



tells how to do conversion from dashes to non-dashes. my point was that that

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 

 to do so but i have to go check the manual. who wins?



 so getopt is better"?



 tells how to do conversion from dashes to non-dashes. my point was that 

 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 

 to do so but i have to go check the manual. who wins?



 so getopt is better"?



 tells how to do conversion from dashes to non-dashes. my point was that 

 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  

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



 (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 

functionality that can't be achieved with D templates. However, I still 

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 

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 

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

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

 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 


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 



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


 I don't believe there is an argument parser in either Phobos 1 or Phobos 2.
 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 next 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
prev sibling parent 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