Ruby/Thor Exit-Status im Fehlerfall

Question

Ich bin neu in Thor (und Ruby) und ich überlege, es in einem Build-Skript zu verwenden, da es gesagt wird, dass es ein Ersatz für Rake (also zu machen). Allerdings bin ich nach einem kurzen Versuch verwirrt über den Fehlerstatus, den es zurückgibt. Ich bin schnell durch das Wiki gegangen, habe aber nichts davon erwähnt.

Mit nur dem ersten "Einfachen Beispiel", test.thor:

class Test < Thor 
    desc "example", "an example task" 
    def example 
    puts "I'm a thor task!" 
    end 
end 

Version #:

eruve>thor version 
Thor 0.18.1 

Ich hat versucht, den folgenden, ein fehlerhafter Befehl Zweck:

eruve>ruby --version; thor test:example badarg; echo exit status: $? 

ruby 2.0.0p195 (2013-05-14 revision 40734) [x86_64-darwin10.8.0] 
ERROR: thor example was called with arguments ["badarg"] 
Usage: "thor test:example". 
exit status: 0 

Es gab also einen Fehler, aber es wird trotzdem mit dem Status 0 beendet ... was bedeutet, dass ich es lieber nicht in einem (n on-ruby) Skript, andernfalls würde das Skript weiter ausgeführt, obwohl es beendet werden sollte. Nachfolgende Fehler können schwierig zu analysieren sein.

Ich muss etwas fehlen, daher meine Fragen:

• Gibt es einen einfachen Weg, um einen Nicht-Null-Status standardmäßig im Falle eines Fehlers (config-Datei, etc.) zu bekommen?

• Wenn nicht, was soll ich tun, um es richtig zu machen?

Vielen Dank.

Answer 1

Basierend auf Bündler-Lösung (vielen Dank @fontno), und weitere Untersuchungen auf meiner Seite, hier ist ein hacken, um es mit einer normalen Shell arbeiten zu lassen. ACHTUNG: es ist nicht elegant, druckt den Ausnahme-Stack-Mist aus, aber ich denke, das funktioniert (bitte zögern Sie nicht, mir etwas anderes zu sagen).

Wie oben geschrieben, hat es das gleiche Verhalten wie zuvor (glaube ich). Nun, nach dem Entfernen der von Thor#ough, sollte es mit dem Status 1 beenden, wenn Thor eine Error ausgelöst hat, so dass einige Kontrolle von z. eine nicht-rubinrote Schale.

eruve>thor test:example badarg; echo $? 
/Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/base.rb:482:in `handle_argument_error': ERROR: thor example was called with arguments ["badarg"] (Thor::InvocationError) 
Usage: "thor test:example". 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/command.rb:35:in `rescue in run' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/command.rb:21:in `run' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/base.rb:439:in `start' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/runner.rb:36:in `method_missing' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/command.rb:29:in `run' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/command.rb:128:in `run' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/lib/thor/base.rb:439:in `start' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/gems/thor-0.18.1/bin/thor:6:in `<top (required)>' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/bin/thor:23:in `load' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/bin/thor:23:in `<main>' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/bin/ruby_noexec_wrapper:14:in `eval' 
    from /Users/eruve/.rvm/gems/ruby-2.0.0-p195/bin/ruby_noexec_wrapper:14:in `<main>' 
1 

eruve>thor test:example; echo $? 
I'm a thor task! 
0 

eruve>thor test:example badarg 2>/dev/null; echo $? 
1 

Prost. PS: Ich frage mich, gibt es in Thor so viele Fallstricke? Wenn es ein erwartetes Verhalten ist, ist seine Absicht/Philosophie mit den Bedürfnissen meines Projekts nicht kompatibel ... Hacks sind keine zuverlässige Lösung.

Answer 2

Gute Frage. Ich habe das auch bemerkt, wenn ich ein thor für ein Projekt verwendet habe. Soweit ich das beurteilen kann, ist dies erwartetes Verhalten. Diese pull request for bundler hat eine interessante Lösung, die für Sie geeignet sein kann.

Sie aktivierte das thor Debugflag, so dass sie den Fehler fangen können und den geeigneten Exit-Status

# bin/bundle 

Bundler.with_friendly_errors { 
    # Set debug flag so we can rescue Thor::error's 
    # and set the correct exit code. 
    ENV["THOR_DEBUG"] = "1" 
    Bundler::CLI.start 
} 


# friendly_errors 

rescue Thor::UndefinedCommandError => e 
    Bundler.ui.error e.message 
    exit 15 
    rescue Thor::Error => e 
    Bundler.ui.error e.message 
    exit 1 

Answer 3

Ich weiß, das wurde bereits beantwortet, aber ich denke, das ist eine bessere Antwort, also dachte ich, ich würde es trotzdem beitragen.

Thor verfügt über eine Methode, die Sie verwenden können, um das Verhalten zu ändern, sodass Fehler Nicht-Null-Beendigungscodes verursachen. Es ist nicht sehr gut dokumentiert (IMHO).

class Test < Thor 
    def self.exit_on_failure? 
    true 
    end 

    desc "example", "an example task" 
    def example 
    puts "I'm a thor task!" 
    end 
end 

Der Standardwert dafür ist unerklärlicherweise false. Ich weiß nicht, warum irgendjemand möchte, dass er sich so persönlich benimmt. Thor issue 244 adressiert dies auch.