Module | Drydock |
In: |
lib/drydock.rb
lib/drydock/screen.rb |
VERSION | = | 0.6 |
Define a command-specific action.
This is functionally very similar to option, but with an exciting and buoyant twist: Drydock keeps track of actions for each command (in addition to treating it like an option). When an action is specified on the command line Drydock looks for command_action or action_command methods in the command class.
action :E, :eat, "Eat something" command :oysters => Fresh::Oysters # Drydock will look for Fresh::Oysters#eat_oysters and Fresh::Oysters#oysters_eat.
Used to create an alias to a defined command. Here‘s an example:
command :task do; ...; end alias_command :pointer, :task
Either name can be used on the command-line:
$ yourscript task [options] $ yourscript pointer [options]
Inside of the command definition, you have access to the command name that was used via obj.alias.
Provide names for CLI arguments, in the order they appear.
$ yourscript sample malpeque zinqy argv :name, :flavour command :sample do |obj| obj.argv.name # => malpeque obj.argv.flavour # => zinqy end
Define a command.
command :task do ... end
A custom command class can be specified using Hash syntax. The class must inherit from Drydock::Command (class CustomeClass < Drydock::Command)
command :task => CustomCommand do ... end
Identical to alias_command with reversed arguments. For whatever reason I forget the order so Drydock supports both. Tip: the argument order matches the method name.
Enable or disable debug output.
debug :on debug :off
Calling without :on or :off will toggle the value.
Define a default command. You can specify a command name that has been or will be defined in your script:
default :task
Or you can supply a block which will be used as the default command:
default do |obj| # This command will be named "default" # ... end default :hullinspector do # This one will be named "hullinspector" # ... end
If with_args is specified, the default command will receive all unknown values as arguments. This is necessary to define explicitly because drydock parses arguments expecting a command name. If the default command accepts arguments and with_args is not specified, drydock will raise an unknown command exception for the first argument.
Tell the Drydock parser to ignore something. Drydock will currently only listen to you if you tell it to "ignore :options", otherwise it will ignore you!
what the thing to ignore. When it equals :options Drydock will not parse the command-specific arguments. It will pass the arguments directly to the Command object. This is useful when you want to parse the arguments in some a way that‘s too crazy, dangerous for Drydock to handle automatically.
Define a command-specific option.
args is passed directly to OptionParser.on so it can contain anything that‘s valid to that method. If a class is included, it will tell OptionParser to expect a value otherwise it assumes a boolean value. Some examples:
option :h, :help, "Displays this message" option '-l x,y,z', '--lang=x,y,z', Array, "Requested languages" You can also supply a block to fiddle with the values. The final value becomes the option's value: option :m, :max, Integer, "Maximum threshold" do |v| v = 100 if v > 100 v end
All calls to option must come before the command they‘re associated to. Example:
option :t, :tasty, "A boolean switch" option :reason, String, "Requires a parameter" command :task do |obj|; obj.options.tasty # => true obj.options.reason # => I made the sandwich! end
When calling your script with a specific command-line option, the value is available via obj.longname inside the command block.
The project name. This is currently only used when printing list of commands (see: Drydock::Command#show_commands). It may be used elsewhere in the future.