* Similar to `:sudo`, gives the ability to run an external command
within a given context.
* Exposes `:bsexec` in DSL; not yet documented
* Fixes#7132 (mount dmg image fails if user does not have StartupItemContext(8))
* part of DSL 1.0 review
* `destination_path` was always a bit vague (it refers to
Cask-specific, version-specific location under
`/opt/homebrew-cask/Caskroom`)
* here renamed `staged_path` to match upcoming command verb
`brew cask stage`
* rename also intended to reduce confusion when we implement
copying as a configurable alternative to symlinking
* transitional `destination_path` methods to remain while
Casks are converted (this was documented as a part of the
DSL, and used by 39 Casks in main repo)
* unrelated variables containing "stage" recast for clarity
from Cask::SystemCommand.run
* stderr and stdout are now separated, though both are available
* :print_stderr is made the default, closer to previous behavior
* exit status can be read from the result object
* plist parsing is more naturally handled in the result object.
The :plist argument to the run method was removed.
* whitespace
- Cask::Container::Pkg
- Cask::Container::Ttf
- Cask::Container::Otf
which are autodetected based on filetypes as with other
containers. Cask::Container::Naked remains available
for explicit use in a container_type stanza.
This is just a matter of semantics: renaming the abstract base
class `Cask::Container::UnarBase` so that it makes sense when
referring to it in a `container_type` stanza.
nstead, determine success by directly testing the intended effect:
does the mount path still exist?
Also:
- retry once on failure.
- silent success if the given mount point did not exist.
These changes are intended to help with unpredictable problems with
the test suite that manifest frequently on Travis.
References: #4975, #4900, #4857
Mysterious `hdiutil` errors are a longtime problem with the
test suite, and the largest cause of false Travis failure
reports.
What appears to happen is that `hdiutil` returns a valid
plist output, but also exits with an error code.
Recently, user errors have been reported which seem to be
related to the same problem (#4857).
After #4892 and #4887, we have have more assurances that mount errors
will be caught elsewhere, if the XML is incorrect/missing, or if the
mounts are not returned.
So, for this special case, it should be safe to simply
ignore the error code from `hdiutil`.
The logic for better errors was already there; this just makes
sure that another exceptional case is handled, and falls through
to the existing error-check.
References: #4857
Adobe Air applications take the form of a .air file that the Adobe Air
runtime then installs and creates a .app -- typically in
/Applications. This patch provides a new container for those .air
files which the Adobe Air runtime installs to the Caskroom as well as
tests for Adobe Air app installations.
Presently, if homebrew-cask doesn't detect the Adobe Air runtime, it
will provide an informative error message and instructions to obtain
it via `brew cask install adobe-air`. This is obviously not ideal and
the installation process for the runtime should be automated in the
future.
For external commands which do not support the doubledash convention
(#2613), wrap file arguments in Pathname.new(file).realpath at the
very last minute. This provides a guarantee against surprises caused
by unusual filenames which might be misinterpreted as flags.
This should not be needed for .qlgenerator or .prefPane, because
(like .app) those are always directories/bundles and therefore must
be transported in some type of container.
- add `run!` method which raises if command does not succeed
- use `run!` when the command we are running must succeed for things to
move forward. this should help produce clearer error messages in
failure scenarios.
- move caveats earlier in the install process so reports can be made
about potential failures
- remove the destination tree on cask install failure, so the cask will
not be considered installed
= New Concept: Cask::Artifact
An Artifact is a file in an extacted container for which homebrew-cask
should take some sort of action on install/uninstall.
== Current artifacts:
- App: link/unlink to ~/Applications
- Pkg: install/uninstall (with sudo)
- Prefpane: link/unlink to ~/Library/PreferencePanes
= New Feature: Preference Pane Handling
Specifying `prefpane 'MyApp.prefPane'` in a Cask causes it to be linked
on install to the correct location for it to show up in System
Preferences.
refs #69
= Removed Commands: linkapps/unlinkapps
These were old and mostly unused and don't really make much sense when
linking/unlinking happens automatically in the install process.
= Changed Behavior: stricter relative pathname requirement
With this refactor, we remove the fuzzy searching for a file in an
extracted container when that file was referenced from `link`
or `install`. There may be some casks that need to be updated due to
this change.
- re-added a lost nil guard on `Dmg` containers
- `FakeSystemCommand` was still returning an array of split lines
instead of a string, even though its real counterpart switched to
string when install/uninstall landed
- flushed out an alfred cli bug
- moved plist parsing down to SystemCommand layer
