GLI swallows standard out

[therealadam]

This simple GLI program doesn't produce any output:

#!/usr/bin/env ruby

require 'gli'

include GLI::App

program_desc "Query the Sifter API"

# flag [:t, :token], :default_value => File.read(File.join(ENV['HOME'], ".sifter
.yml"))

pre do |globals, command, options, args|
  # Connect to Sifter
end

command :projects do |c|

  c.action do |globals, options, args|
    puts "projects!"
    $stdout.puts "kittens!"
    $stderr.puts "puppies!"
  end

end

exit run(ARGV)

Invoking it:

$ bundle exec bin/sifter projects
$ rbenv version
1.9.3-p327-perf (set by /Users/adam/.rbenv/version)

I've had this problem a couple times, only to find it mysteriously resolve itself later. I think it has to do with performing IO inside an action definition.

[davetron5000]

This had my head scratching, but it's because the pre block is not evaluating to a truthy value.

If you change pre to just be true, it works. Add a raise in your action block and you can see that without the pre evaluating to true, it doesn't blow up - the action block isn't being called.

To make matters worse, the app exits with zero, which I can see as being wrong.

I can think of a few ways to make this situation not so confusing:

• if pre is falsey, app should exit nonzero. This might break backwards compat, although the docs don't really indicate that the app exits zero if pre is false - this feels correct to me.
• if pre evaluates to exactly nil (i.e. a proxy for an empty body), print as much on stderr
• print the pre block's result if GLI_DEBUG is set in the env.

[therealadam]

I'd thought of pre like a before filter in Sinatra/Rails. Is it really closer to a precondition?

If it's a precondition, I think the semantics you have now make sense, but the API needs better explanation. The first and third options seem right in this case.

If it's not a precondition, I don't think it should worry about the return value of the block.

[davetron5000]

Fixed and/or better in 2.6.0

[simonholroyd]

This still tripped me up in 2.6.0.

pre do |global_options,command,options,args|
  puts 'hi'
  # true
end

This results in a GLI::CustomExit prior to any commands executing. Toggling the #true results in commands being executed as normal. (In both cases 'hi' is printed as expected)

edit: Sorry on further reading of the above, seems like this is (as you decided) expected behavior. I think that the docs at http://davetron5000.github.io/gli/ could still better explain this behavior.

[davetron5000]

Yeah, that's because puts evaluates to nil, which is falsey, which GLI
interprets as "the pre block failed - stop processing". Before 2.6 this
would happen, but the app exits zero. Now it still happens, but the app
exits nonzero. That seemed to be the smallest change to make. I suppose
there could be a PreBlockFailed exception, or even an actual stderr
message that "pre-conditions failed"?

Dave

---

Buy My Book: http://www.awesomecommandlineapps.com
My Blog: http://www.naildrivin5.com/blog
Fork me on Github: http://davetron5000.github.com

On Wed, Jun 26, 2013 at 11:49 AM, Simon Holroyd notifications@github.comwrote:

This still tripped me up in 2.6.0.

pre do |global_options,command,options,args|
puts 'hi'

trueend

This results in a GLI::CustomExit prior to any commands executing.
Toggling the #true results in commands being executed as normal.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/146#issuecomment-20058022
.

[simonholroyd]

I think the behavior is fine as is, but yea either an exception or a just a heads up in the docs to those of us who are gonna assume we can send output in pre for debugging purposes, get no output, and assume the problem is somewhere in our own program.

[davetron5000]

Make sense. Do you think a more strongly-worded comment in the generated
pre block would be sufficient? I updated the rdoc of pre to indicate
what happens if its falsey, but it's a bit of a stretch to expect people
piece that all together (the rdoc isn't the first place you look when your
app acts weird :)

Dave

---

Buy My Book: http://www.awesomecommandlineapps.com
My Blog: http://www.naildrivin5.com/blog
Fork me on Github: http://davetron5000.github.com

On Wed, Jun 26, 2013 at 12:25 PM, Simon Holroyd notifications@github.comwrote:

I think the behavior is fine as is, but yea either an exception or a just
a heads up in the docs to those of us who are gonna assume we can send
output in pre for debugging purposes, get no output, and assume the
problem is somewhere in our own program.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/146#issuecomment-20060956
.

[simonholroyd]

yea, i think that sounds great. The rdoc wasn't the first place I looked, for sure.

[davetron5000]

This improvement is in 2.6.2