Trollop FAQ ----------- Q: Why is it called "Trollop"? A: No good reason. Something something option parsing. Q: Why should I use Trollop? A: Because it will take you fewer lines of code to parse commandline arguments than anything else out there. Like this: opts = Trollop::options do opt :monkey, "Use monkey mode" opt :goat, "Use goat mode", :default => true opt :num_limbs, "Set number of limbs", :default => 4 end That's it. 'opts' will be a hash and you can do whatever you want with it. You don't have to mix processing code with the declarations. You don't have to make a class for every option (what is this, Java?). You don't have to write more than 1 line of code per option. Plus, you get a beautiful help screen that detects your terminal width and wraps appropriately. Q: What is the philosophy behind Trollop? A: Trollop does the parsing and gives you a hash table of options. You then write whatever fancy constraint logic you need as regular Ruby code operating on that hash table. (Trollop does support limited constraints (see #conflicts and #depends), but any non-trivial program will probably need to get fancier.) Then if you need to abort and tell the user to fix their command line at any point, you can call #die and Trollop will do that for you in a pretty way. Q: What happens to the other stuff on the commandline? A: Anything Trollop doesn't recognize as an option or as an option parameter is left in ARGV for you to process. Q: Does Trollop support multiple-value arguments? A: Yes. If you set the :type of an option to something plural, like ":ints", ":strings", ":doubles", ":floats", ":ios", it will accept multiple arguments on the commandline, and the value will be an array of the parameters. Q: Does Trollop support arguments that can be given multiple times? A: Yes. If you set :multi to true, then the argument can appear multiple times on the commandline, and the value will be an array of the parameters. Q: Does Trollop support subcommands? A: Yes: you can direct Trollop to stop processing when it encounters certain tokens. Then you can re-call Trollop with the subcommand-specific configuration to process the rest of the commandline. See the third example on the webpage. (And if you don't know the subcommands ahead of time, you can call #stop_on_unknown, which will cause Trollop to stop when it encounters any unknown token. This might be more trouble than its worth if you're also passing filenames on the commandline.) Q: Why does Trollop disallow numeric short argument names, like '-1' and '-9'? A: Because it's ambiguous whether these are arguments or negative integer or floating-point parameters to arguments. E.g., is "-f -3" a negative floating point parameter to -f, or two separate arguments? Q: What was the big change in version 2.0? A: The big change was boolean parameter (aka flag) handling. In pre-2.0, not specifying a flag on the commandline would result in the option being set to its default value; specifying it on the commandline would result in the option being set to the opposite of its default value. This was weird for options with a default of true: opt :magic, "Use magic", default: true Using --magic with the above configuration would result in a :magic => false value in the options hash. In 2.0, we introduce the GNU-style notion of a --no-x parameter. Now, specifying --x will always set the option :x to true, regardless of its default value, and specifying --no-x will always set the option :x to false, regardless of its default value. The default value only comes into play when neither form is given on the commandline. E.g.: opt :magic, "Use magic", :default => true Using --magic will result in :magic => true, and --no-magic will result in :magic => false, and neither will result in :magic => true. There is one exception: if the option itself starts with a "no_", then you'll get the opposite behavior: opt :no_magic, "Don't use magic", :default => true Using --magic will result in :no_magic => false, and --no-magic will result in :no_magic => true, and neither will result in :no_magic => true.