A consistent set of options for Wget

This page discusses the concerns for preparing a consistent command line interface before the actual implementation of a new version of Wget, and before the implementation of new features adding new options to the interface. Doing so early, allows for more time to look critical at what earlier has seemed obvious.

Concerns and negative examples

The following is a list, the set of options should ideally adhere to:

• Options should be clearly distinct: introducing options --server-time and --time-server would be asking for trouble.
• Patterns in options should be consistent: -v and -nv suggest that prepending an n negates the option, but -nc and -c do not match that pattern.
• Keywords should have one function only: force occurs as a segment of two options, but also as a value.
• Options should be descriptive: --no-clobber is so much a misnomer that it's user-documented as such (for certain cases).
• Options should control one distinct area of functionality, which area does not vary based on the values of other settings.
• A triple state should not be implemented as two booleans: how verbose will Wget be after specifying --no-quiet?
  • I'm not sure about that one. I understand the sentiment, but it's a very wide practice to have a -v and a --quiet (or --silent) option. However, perhaps -v could control the triple state, and -q would be considered an "alias" option to the least-verbose of those states. --Micah
• Where possible, options should only match options in other software by name if they do so in effect as well.

Requirements

• Argument-taking options should not be negatable, unless a way is found to negate all arguments.
  • I'm not sure I understand this. --Micah
• Options should write terms in full, except when functioning as a short-cut.
  • Not sure I understand this either. --Micah
• Options should be limited in length, especially in the number of segments used.
• The commandline should function as a single line configuration file, meaning all options should be equal for both methods, and all options should have a natural end so more options can be specified behind them.
  • Traditionally, the natural end is the end of the argument, isn't it? If you mean that options should never take more than one shell-split argument, I would agree. --Micah
• New options should be determined early, so enough time will remain for checking.