* "Canonical App Name" becomes "Simplified App Name"
* devscript `cask_namer` renamed to `generate_cask_token`
* doc file `CASK_NAMING_REFERENCE.md` renamed to `cask_token_reference.md`
* DSL uses `"#{token}"` for interpolation instead of `"#{title}"`
* documentation text
* backend code (variables, method, class names)
* error message text
* tests
* code comments
* Cask comments
* emphasize `tags :name`
* doc: use "vendor" consistently instead of "developer"
* doc: many man page argument descriptions were incorrect
* incidental clarifications
Many backend variables similar to `cask_name` or `cask` have
been standardized to `cask_token`, `token`, etc, resolving a long-
standing ambiguity in which variables named `cask` might contain
a Cask instance or a string token.
In many places the docs could be shortened from "Cask name" to
simply "token", which is desirable because we use the term "Cask"
in too many contexts.
* `checklinks` is a very simple implementation useful only for development purposes
* it has no test coverage, only one line of documentation
* users regularly experiment with it and break it, especially
`brew cask checklinks` with no arguments, which tests all Tapped Casks
- Show a more user-friendly error message when dealing with an option whose (mandatory) argument is missing.
- Likewise, we show a more user-friendly error message when a given option is ambiguous. Examples:
- Given `-f`, the parser successfully expands to `--fontdir`.
- Given `-c`, we fail to expand because the parser can’t tell if the user means `--caskroom` or rather `--colorpickerdir`. This exception now results in a nicer error message.
- Some commands now result in a consistent error message when a required cask name is missing.
This affects all stable commands which require one or more cask names as arguments, i. e. `cat`, `create`, `edit`, `fetch`, `info`, `install`, `uninstall`, and `zap`.
- Up to now, the commands `cat`, `create`, `edit`, and `info` used to treat any unknown option as a cask name. This commit changes that behaviour to make it consistent to the rest of the commands (like `fetch`, `install`, `uninstall`, and `zap`), who have silently discarded any unknown option in the past, and continue to do so.
* `zap` was previously supported as a noop for forward-compatibility
* Also adds restrictions against relative paths in `uninstall :files`
* Also documents safety conventions for `uninstall :files`
Covering all cases
- external commands as executables
- external commands as Ruby libraries
- built-in command verbs
This is intended as a development aid.
A side benefit is that an external command can be constructed
to use a `run` method, rather than having to accomplish everything
at `require` time.
- based on abstract class `Cask::CLI::InternalUseBase`
- interal-use class file names follow `internal_<verb>.rb`, but the "internal" is dropped for the CLI
- internal-use verbs start with underscore at CLI
- internal-use verbs are invisible in the usage document
global replace of:
'phinze/homebrew-cask' -> 'caskroom/homebrew-cask'
'phinze/cask' -> 'caskroom/cask'
'phinze/homebrew-testcasks' -> 'caskroom/homebrew-testcasks'
and various other specific places that needed updates
<3 the homebrew-cask community!
When user run `brew cask` it will list all commands out.
There is a blank help command call issues_url which caused by the newly
introduced constant from #2971
- add new file "cask/utils.rb" analogous to "utils.rb" in Homebrew
- define odebug and odumpcask, analogs of ohai and friends, but
which only give output when --debug is in effect
- move the debug setting from an instance variable in Cask::CLI
to a method Cask.debug, defined in "lib/cask/options.rb", which
was added in #2276. (Perhaps options.rb should be merged back
into Cask::CLI).
- sprinkle odebug statements liberally throughout the codebase
- update tests
