Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re^3: Command line options

by graff (Chancellor)
on Nov 02, 2011 at 07:52 UTC ( #935318=note: print w/replies, xml ) Need Help??

in reply to Re^2: Command line options
in thread Command line options

Having "special interactions" among different options seems like a bad idea. If you actually have specific cases where the kinds of logic you describe seem necessary, there's probably a way to simplify the interface. If you're just imagining that such situations might arise, don't waste your time worrying about it, because if they do, there should be a way to simplify things.

You write user manuals for these tools, right? If an accurate description of how the options work is too complicated, users are going to use it the wrong way and get results they don't want.

Replies are listed 'Best First'.
Re^4: Command line options
by rpelak (Sexton) on Nov 02, 2011 at 17:12 UTC
    I do have specific situations...
    They are hard to describe as they are, without a lot of background, so I will try to adjust the situation to something that is more commonly known...

    Think build scripts design to build multiple tools independently...
    you run a command to do a build. If you are in a directory for a specific tool, it assumes that it the tool you want to build, if not there is a commonly tool you likely want to build, or you can tell it which one. So if you tell it, that always wins. As for derived, think of the platform, different tools have different platforms they can be built for... so a good default is hard to come by, but there may be one that is good for 80% of the tools, but if you determine that the tool is not one of those 80% (by derivation or user input) you want to derive the most likely platform for that tool, and unless the user gives you one specifically, you want to use the derived over the default.

    Now the obvious answer that jumps out, is to set the default to "" and then you will "know" if the user passed in a value as it isn't "". But in the real case, "" is a possible value that the user might pass, and in theory there isn't anything you could set the default to that might not be something the user might pass in. And of course giving it some crazy string and having that show up in the auto generated help text would be rather ugly, and shouldn't be needed. If only you knew the value came from the user vs the default, all would be well.

    also in the real case, the tool is used without any args 85% of the time, and in the same env, so it does the same thing. And that env doesn't provide enough to derive "all" of the args, so some have to have defaults of real values. Yet those same args that have to have real defaults, would be easily derived in many of the other 15% of uses. So you can't use a bogus default value to tell you if the user passed something in, and you have to let the user pass something in if they want, yet if they don't in some 15% of the cases the derived value is better then the default...

    Does that make sense?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://935318]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2018-05-23 19:48 GMT
Find Nodes?
    Voting Booth?