emyl / vagrant-triggers

Allow the definition of arbitrary scripts that will run on the host before and/or after Vagrant commands.
MIT License
546 stars 35 forks source link

Support non buffered command output #18

Closed nocive closed 9 years ago

nocive commented 10 years ago

First of all, great work! Valuable plugin which I cannot live without for all my vagrant setups!

That said, I think that supporting interactive commands would be a great feature to add to this. It would allow, for example, to automatically install dependencies on the host OS in case they're missing. This is just one usage scenario, but I'm sure it would be useful for many more things. No idea if it's a pain to implement or not, so apologies if it's too much to ask for :)

emyl commented 10 years ago

Hi!

Please, could you provide an example of what you're trying to achieve? I'm not sure what you're referring when you say interactive commands. Does the following example sound good for your use case?

config.trigger.after :up, :vm => /vm1/ do
  answer = ask("What's your name? ")
  info("Answer: #{answer}")
end
Bringing machine 'vm1' up with 'lxc' provider...
==> vm1: Running triggers after up...
    vm1: What's your name? Emyl
==> vm1: Answer: Emyl
nocive commented 10 years ago

Hi emyl,

Thanks for getting back on this. Looking back and reading my feature request is not all that clear what I actually wanted to get across, apologies for that, it was probably already too late that day :) The feature request should read "support non buffered output for executed commands".

Interaction is indeed supported with no issues, the problem is that the user only sees the output (eg, an input prompt from inside a bash script) after the command is finished when vagrant-triggers dumps it. I guess one way to get around the problem is doing what you did in your example, asking for the input in plain ruby and then just pass those arguments to whatever shell script you want to run.

Despite the fact that it works I believe it's better to have the logic contained inside the scripts that you are executing and keep it out of the Vagrantfile itself, with the extra advantage that you can reuse the same scripts for several vagrant setups without repeating yourself as much.

Let me know if you need further details or a practical example.

emyl commented 10 years ago

All it's clear :wink:

It should be feasible. The plugin relies on Vagrant::Util::Subprocess for running commands, and that class seems to support non-buffered output:

https://github.com/mitchellh/vagrant/blob/bb052366f7f9616666299a97edcceadae007394a/lib/vagrant/util/subprocess.rb#L16-18

I'll take a deeper look to it. Tagged as enhancement.

nocive commented 10 years ago

Awesome! Thanks :)

nocive commented 9 years ago

:trophy: thanks :)