"superdan" <super@dan.org> wrote in message
news:g4lcjp$2dg9$1@digitalmars.com...
> Nick Sabalausky Wrote:
>>
>> The getopt version forces you to list each variable three times. Once for
>> the variable itself, once more to tell getopt what it's called, and a
>> third
>> time to tell getopt where it is. That's highly redundant. They're only
>> listed once for the C# version.
>
> narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say;
>
> bool showControlChars;
> getopt(args, "show-control-chars", &showControlChars);
>
> i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins?
>

The C# one could be easily modified to use a dash-based convention. Flip a switch, it's dash-based, flip it back, it's camel-cased. If for some bizarre reason you wanted an inconsistent style, that could be done too - and you'd only have to specify it for the deviating cases. Obviously that can be done in D, but I'm saying that the C# approach is perfectly capable of the same thing as well.

But at this point you're really just splitting hairs anyway. My main point was simply that attributes allow for fewer tradeoffs between DRY-ness and power. Command line parsers are good illustrative examples of that. Although, as Lutger pointed out, D's vastly superior template system does help compensate for the lack of attributes.

> second, yarp i do define the var and then specify it in the getopt thing. but that's a good thing, gives me freedom. i can put it locally, or at module level, or in another object. but in c# it's always a member of a new type. shit. i have to define a freakin' *type*. that's useless baggage. why do i have to define a type to parse my command line shit. thanks but i'll use getopt.
>

Tossing related variables all over the place just because you don't feel like making one extra class smacks of laziness. Sure, that can work fine for trivial programs, but the first time you work on anything substantial (tens of thousands of lines of code), you'll quickly see it blow up in your face. Running away from modularization is just bad design.

>> (The getopt version could probably be
>> changed to extract the name from the variable using templates and traits
>> though, and it could probably eliminate the rest of that redundancy by
>> sticking the vars into a class or stuct, but then it would lose the
>> ability
>> to let you specify options for each var. Attributes would bring that
>> ability
>> back without creating reduncancy).
>
> run ls --help. you'll see there are 18 options with dashes in'em and 23 without. that's like 40/60.
>
> but then maybe some-option-x could be converted automatically to someOptionX by a template. heh we have an enhancement idea right there.
>
>> Regarding the C# version:
>> - Sticking the variable declarations inside a class is trivial.
>
> yarp but i have to have a class in the first place.
>

You're already declaring the variables you need in the first place. May as well just put them in the same place (basic good design anyway), and stick "class xx {}" around it. Takes all of about ten seconds. And if you're too impatient to take few extra seconds up-front, or even a few extra minutes (development time, not runtime, of course), then you're in the wrong field.

>> - All of the stuff in square brackets (attributes) are optional.
>> (If you do specify any attributes, then the AttributeType is required,
>> however I was able to remove that restriction in about two minutes by
>> adding
>> two trivial constructors.)
>
> two minutes for command line shit is two minutes too many. that's the problem. command line is easy shit. should be a !brainer. everybody doing command line shit asks me to waste time with their crappy api. getopt in phobos is the first ever to ask me to be done with it in seconds and move on. i think it makes it look so simple people don't see what a work of art it is.
>

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

>> - You can specify a custom help string for each element.
>
> guess this could be improved in getopt:
>
> uint shits;
> getopt(args,
> "shits number of shits given for this run", &shits);
>
> so then the space separates the option from the help string.
>

I wasn't saying getopt couldn't do that. I was responding to this: "...the no-good generated help string that always is too short and uninformative to help shit." If my response wasn't relevant to that statement, then it's because your original post wasn't very clear. Lots of whining and cussing, not much content or coherency.

>> - The fact that there could be multiple files *IS* inferred by using an array of strings. (At least if you don't use any attributes, that is. But that can be fixed fairly easily too.)
>
> hum. so then why would the attributes be needed in the first place.

1. For all of the other attribute options besides that one. 2. In this particular case, the important thing is not whether or not it takes multiple inputs. The important thing is the distinction between "Multiple" and "MultipleUnique". Ie, whether or not ["fileA", "fileB", "fileA"] is allowed.

>
>> If anyone's interested, I found a link: http://www.codeplex.com/CommandLineArguments
>
> sorry won't read. :)
>

That wasn't directed at you. I had a feeling you wouldn't be interested ;)

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

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.

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

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

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

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

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.

Robert Fraser Wrote:

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

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

nice try though. one attempt at irony missed, two to go.

"superdan" <super@dan.org> wrote in message news:g4mmed$a2u$1@digitalmars.com...
> Robert Fraser Wrote:
>
>> superdan wrote:
>> > narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say;
>> >
>> > bool showControlChars;
>> > getopt(args, "show-control-chars", &showControlChars);
>> >
>> > i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins?
>>
>> So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?
>
> narp you are confused. there must be some option in the c# attributes that tells how to do conversion from dashes to non-dashes. my point was that that needs to be looked up whether or not you are versed in c# proper. with std.getopt you don't need to look that up because the string is distinct from the variable it binds to.
>

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

> nice try though. one attempt at irony missed, two to go.

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

Nick Sabalausky Wrote:

> "superdan" <super@dan.org> wrote in message news:g4mmed$a2u$1@digitalmars.com...
> > Robert Fraser Wrote:
> >
> >> superdan wrote:
> >> > narp. getopt is better for 2 reasons. first, if i want to have an option with a dash in it, with getopt you say;
> >> >
> >> > bool showControlChars;
> >> > getopt(args, "show-control-chars", &showControlChars);
> >> >
> >> > i and you and anyone who's used getopt once knows how to do that. but i have no idea how to do that in c#. there may be some shitty attribute to do so but i have to go check the manual. who wins?
> >>
> >> So, just to be clear, your argument is "I don't understand the C# way, so getopt is better"?
> >
> > narp you are confused. there must be some option in the c# attributes that tells how to do conversion from dashes to non-dashes. my point was that that needs to be looked up whether or not you are versed in c# proper. with std.getopt you don't need to look that up because the string is distinct from the variable it binds to.
> >
> 
> getopt has plenty of options that need to be looked up.

Hello Nick. Sorry maybe I came in thread late. I disagree, std.getopt has 7 options and a few syntax. many options are "no" for other options. If I understand what super dan write, I think he has a good points. There is repeat a little but it is small price for simplicity of library. And I disagree when you said that just wrap class {} around variables is not important. it is very important. more types should not add without necessity. I have some variable in main() that I parse and maybe few globals. Why put they all in a class? It is not wanted complexity not justified.

Also the modular part is not good argument. Code to handle command line is unique, never called from the app. Only once. Should be there in line. Design for modular there is not justified. I think even is mistake. Parse arguments is simple problem and should have simple solution. std.getopt is simple solution. (only one function!) All other are complicated. It means they did not see how simple problem is. Thank you, Dee Girl