[mcantor]

Here's another one:

Provide explicit flags for default behavior.

For example, if your lines-of-code counting utility excludes preprocessor directives by default, and includes them when you pass "-i", provide an "-x" switch that signals to use the default behavior. This way, when someone wants to write a bash script that uses your utility, they can do this:

    case $include_directives in
    y)
        LOC_FLAGS='-i';;
    n)
        LOC_FLAGS='-x';;
    esac

    myloc $LOC_FLAGS

This has three benefits:

1.) It's explicit, and thus more obvious and clearer.

2.) It's more consistent, so there's no risk of empty/unset variables, whitespace, or other edge conditions screwing up a delicate munging operation.

3.) It's change-tolerant, so if future versions of your utility change the default behavior, scripts will continue functioning as expected.

[a3_nm]

Other benefit: if you aliased myownloc="myloc -i --complicated_option", you can run myownloc -x to selectively disable the -i switch.

[reinhardt]

What about the disadvantages?

- It doubles the number of flags of the program.

- It allows invalid or ambiguous combinations: is `myloc -i -x` valid? If yes which flag takes precedence?

It seems these must outweigh the benefits or it wouldn't be so uncommon.

[joeyh]

Don't call it -i and -x, call it -i and --no-i or better, -i, --include and --no-include. Some getopts can provide this automatically.

Last flag wins is a common choice because it allows some script to contain yourcommand --include $@ and then you can override with --no-include.

[ams6110]

I've seen two conventions for conflicting flags: complain and bail out, or "last one wins" so in your example, -x.

[keeperofdakeys]

"- It doubles the number of flags of the program."

I don't agree with this. One of the advantages of command line programs is that you can have a large amount of possible arguments, but it doesn't really matter for the user, as long as there is some way to give the most common (like --help and --long-help, or listing the important options in the man page, then have a full list) . This is where GUI's fall down, you must process all options to get to ones you want; where as command line programs can have just the options you want set mentioned. (have you seen mplayer's man page lately?)

As well as having negating arguments, you also want long versions. This is so, when used in scripts, the arguments passed to a program make some kind of sense.

With your precedence argument, just look at some of the standard tools. For rm, -f will override -i. I want this behaviour, personally. It seems 'obvious' that it should be that way.

[sjs]

It doesn't necessarily double the number of flags, it doubles the number of boolean flags. And if you use a convention like joeyh mentioned then the length of your help text won't double, nor will the cognitive burden on users who have to remember the options.

A disadvantage of this system is that --no-x might not always make sense or read well so if you make it consistent it may be weird. On the other hand if you use --no-this and --without-that then you are increasing the documentation and cognitive burden on yourself and your users. For most geeks this is admittedly a pretty minor disadvantage but it's the only one I have off the top of my head.