Bug report: core: brew cask command prints "Kernel.exit" to stdout, breaking scripts

[zmwangx]

Description of issue

I'm currently using latest master, 1a25170. A brief demonstration:

$ HOMEBREW_VERBOSE= HOMEBREW_CASK_OPTS= brew cask info google-chrome 2>/dev/null
google-chrome: latest
Google Chrome
https://www.google.com/chrome/
/opt/homebrew-cask/Caskroom/google-chrome/latest (3 files, 124K)
https://github.com/caskroom/homebrew-cask/blob/master/Casks/google-chrome.rb
==> Contents
  Google Chrome.app (app)
==> Caveats
The Mac App Store version of 1Password won't work with a Homebrew-Cask-linked Google Chrome. To bypass this limitation, you need to either:

  + Move Google Chrome to your /Applications directory (the app itself, not a symlink).
  + Install 1Password from outside the Mac App Store (licenses should transfer automatically, but you should contact AgileBits about it).

Kernel.exit

Same for other cask subcommands. Apparently, Kernel.exit shouldn't be printed to stdout, and actually shouldn't be printed at all without some form of --verbose. This breaks my personal plugin script that prints the staged path of a cask (as well as other scripts depending on that plugin), as it now contains an extra line.

P.S. Here's my plugin script brewcask-stagedpath.rb:

command_name = ARGV.shift
cask_token = ARGV.shift

cask = Hbc.load(cask_token)

if cask.installed?
  puts cask.staged_path
else
  exit 1
end

$ brew cask stagedpath google-chrome 2>/dev/null
/opt/homebrew-cask/Caskroom/google-chrome/latest
Kernel.exit

Output of brew cask whatevercommand --verbose

N/A, see description above.

Output of brew doctor

https://gist.github.com/anonymous/e9a2c6f167a319019c54

Output of brew cask doctor

https://gist.github.com/anonymous/be228d1b84a2f0ef6832

[vitorgalvao]

Please always follow the reporting bugs guide. To do so, edit the top post and then comment after this one so I can check back.

Closing in the meantime, because a number of people never report back and it’s useless to keep the issue open in that case and without all the required information.

Also, be sure to run brew uninstall --force brew-cask; brew update once, if you haven’t before.

[zmwangx]

Please always follow the reporting bugs guide.

Sorry, updated. In my defense, it seems that the templates have been in place for less than a week, and I've filed reports before, so hopefully it's understandable that I didn't check the contribution guidelines again.

I put the output of doctors in separate gists because I don't want to have a wall of not-so-relevant output in the issue description. Please let me know if you really want to have them inline.

Also, be sure to run brew uninstall --force brew-cask; brew update once, if you haven’t before.

Yes I've done that before reporting. In fact, I suspect that this issue is caused by the new behavior, although I haven't really tested.

[adidalal]

Thank you for updating your issue with the info.

Kernel.exit seems like a Ruby issue, from a quick google search. Do you have ruby installed via brew, only the system ruby, rbenv, or something else?

For reference, I don't have such behavior and I'm using brew's ruby.

 [ ~ ] > ruby --version --verbose
ruby 2.2.4p230 (2015-12-16 revision 53155) [x86_64-darwin15]

Also, can you check if the problem persists with a different shell? (ie. bash)

[zmwangx]

Do you have ruby installed via brew, only the system ruby, rbenv, or something else?

I have rubies from system, brew, and rvm, but I don't think it matters, because brew always picks up the system ruby anyway (I'm on 10.11.2, system ruby version ruby 2.0.0p645 (2015-04-13 revision 50299) [universal.x86_64-darwin15]):

HOMEBREW_RUBY_PATH="/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby"

on Darwin (https://github.com/Homebrew/homebrew/blob/master/bin/brew#L29-L37), unless both HOMEBREW_DEVELOPER and HOMEBREW_RUBY_PATH are set. And switching ruby on my part doesn't seem to change anything. Neither does switching shell help. Also, this behavior is brew-cask specific; it doesn't show up on brew commands unless there's an error (but I can confirm that Kernel.exit is indeed printed on stdout when there is an error, which is rather surprising).

I don't have such behavior and I'm using brew's ruby.

Weird.

[zmwangx]

Okay, I even went ahead and set both HOMEBREW_DEVELOPER and HOMEBREW_RUBY_PATH; same thing:

> /usr/local/bin/ruby --version
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15]
> export HOMEBREW_DEVELOPER=yes HOMEBREW_RUBY_PATH=/usr/local/bin/ruby
> HOMEBREW_VERBOSE= HOMEBREW_CASK_OPTS= brew cask info google-chrome 2>/dev/null
...
Kernel.exit

[Amorymeltzer]

If I may, I think it's connected to your use of HOMEBREW_VERBOSE=. The new brew-cask doesn't seem to like it. If you remove that, it will go away. On my end:

> brew cask info google-chrome
google-chrome: latest
Google Chrome
https://www.google.com/chrome/
/opt/homebrew-cask/Caskroom/google-chrome/latest (368 files, 364M)
https://github.com/caskroom/homebrew-cask/blob/master/Casks/google-chrome.rb
==> Contents
  Google Chrome.app (app)
==> Caveats
The Mac App Store version of 1Password won't work with a Homebrew-Cask-linked Google Chrome. To bypass this limitation, you need to either:

  + Move Google Chrome to your /Applications directory (the app itself, not a symlink).
  + Install 1Password from outside the Mac App Store (licenses should transfer automatically, but you should contact AgileBits about it).

and

> brew -v cask info google-chrome
google-chrome: latest
Google Chrome
https://www.google.com/chrome/
/opt/homebrew-cask/Caskroom/google-chrome/latest (368 files, 364M)
https://github.com/caskroom/homebrew-cask/blob/master/Casks/google-chrome.rb
==> Contents
  Google Chrome.app (app)
==> Caveats
The Mac App Store version of 1Password won't work with a Homebrew-Cask-linked Google Chrome. To bypass this limitation, you need to either:

  + Move Google Chrome to your /Applications directory (the app itself, not a symlink).
  + Install 1Password from outside the Mac App Store (licenses should transfer automatically, but you should contact AgileBits about it).

Kernel.exit

[zmwangx]

I just confirmed my suspicion that this was caused by the tap-only PR #15381.

> cd /usr/local/Library/Taps/caskroom/homebrew-cask
> git checkout 5a961389ff098beea56aa3e511aa09540234ef5e  # pre tap-only
> brew install brew-cask
> brew cask info google-chrome  # no problem
...
> git checkout d31e7fcc8d60f44e8bb1c60507406e23e67d48bb  # the merge commit
> brew uninstall --force brew-cask
> brew cask info google-chrome  # BAM!
...
Kernel.exit

[zmwangx]

@Amorymeltzer Huh that's right, apparently setting it to null is not enough, I have to fully unset it.

> unset HOMEBREW_VERBOSE
> brew cask info google-chrome  # there it is, no Kernel.exit this time
...

Still, probably something to fix? brew's native commands don't print Kernel.exit (neither stdout nor stderr) unless in case of an error. And verbosity on stdout is never a desired thing anyway.

[adidalal]

Looks like https://github.com/caskroom/homebrew-cask/blob/master/lib/hbc/cli.rb#L226 is where it's getting the verbose option from, though the Kernel.exit seems to be a side effect of moving to a tap directory.

[jawshooah]

@zmwangx Looks like this may be an issue for Homebrew, not us: https://github.com/Homebrew/homebrew/blob/80bdf34/Library/brew.rb#L178

[zmwangx]

@jawshooah Hmm sounds right, but I imagine it would be hard for me to press them to switch to stderr, since they seem to dump error-related stuff to stdout in more than one place, and more importantly, their native commands do the (almost) right thing of only dumping when there is an error...

I suppose the Kernel.exit messages here are triggered by the exit 0's in lib/hbc/cli.rb (I'm not familiar with Ruby)? Then is it possible to get rid of them to avoid triggering the SystemExit exception (when there's really no exception)?

[zmwangx]

In any case, can we agree that this is a minor regression?

[Amorymeltzer]

So, in Homebrew/legacy-homebrew/issues/46387 and Homebrew/legacy-homebrew/pull/46790 brew behavior was changed to treat -v et al. as --version if it's the first and only thing in ARGV, but if not, put it at the end and treat it as --verbose. It seems that here brew is interpreting a --verbose flag rather poorly for cask. You can see that it's brew's error message by editing your local version of /usr/local/Library/brew.rb, per @jawshooah.

[zmwangx]

I know. What I'm saying is lib/hbc/cli.rb calls exit 0, which is picked up by rescue SystemExit and triggers the "error" message. brew's native commands don't do that. Correct me if I'm wrong.

[jawshooah]

I suppose the Kernel.exit messages here are triggered by the exit 0's in lib/hbc/cli.rb

That would probably make things easier, but no. cli.rb only does exit 0 after running an external command with require (here and here), and that's not what's happening here.

The SystemExit is completely unavoidable, since brew invokes us by require-ing our entry script, and explicitly exiting with 0 or 1.

[jawshooah]

In any case, can we agree that this is a minor regression?

Yes, this is a minor regression. The question is whether we can do anything about it from our side, and it looks like the answer is no.

Please feel free to open an issue over on Homebrew and link back here.

[zmwangx]

Thanks for the clarifications (as I said I'm not familiar with Ruby).

The question is whether we can do anything about it from our side, and it looks like the answer is no.

Sounds reasonable. Any suggestions on how to solve this problem, i.e., what to report to homebrew/homebrew?

[jawshooah]

I'd suggest you open an issue reporting exactly the problem you've reported here, and linking back to this issue for reference.

[jawshooah]

I've removed an exit 0 in cmd/brew-cask.rb in 8a2aaba that would have prevented this from being resolved with an upstream fix. An upstream fix is still needed, though.

Edit: also removed unnecessary exit 0s in lib/hbc/cli.rb in 43233b2.

[zmwangx]

Thanks, reported in Homebrew/legacy-homebrew#47099.

[MikeMcQuaid]

It's because of setting HOMEBREW_VERBOSE.

[jawshooah]

I believe we've done all we can here, so I'll go ahead and close this.