I guess this isn't easily solvable because Unix. If so, a FAQ or something in the README why this happens (or how to avoid it) would be super.
Please give us more info! See CONTRIBUTING.
You're an open source developer, I demand that you do my work for me and fix all my issues and fix me a sammich.
Apologies: I assumed this was a known issue with guard, as I've seen it mentioned elsewhere, but it was under the "eh. too hard, doesn't hurt anybody, won't fix" heading.
Using Ruby 1.9.3 on OSX, my Gemfile is long and contains stuff I can't make public, so I'm going to grep it:
➜ be-site git:(master) ✗ grep guard Gemfile
➜ be-site git:(master) ✗ grep guard Gemfile.lock
guard (>= 0.4.0)
guard (>= 1.1)
guard (>= 1.1)
Issue occurs most commonly when attempting to interrupt guard-rspec runs, especially if I (say) switch branches in git and don't want the tests to burn my CPU for minutes. Issue is not reliably reproducible, but I can easily say that ^C rarely does what I expect it to in this combination, which is to stop the currently running task, run no others, and drop me back to the guard prompt.
This regularly happens to me too. Ubuntu 12.04, zsh 4.3.17, tmux 1.6, Ruby 1.9,3-p327, Rails 3.2.11, up-to-date guard, guard-spork and guard-livereload with stock (init) config. Pry 0.9.10 is installed and Guard's using that. If I exit from the prompt, it shuts down cleanly. If I C-c, I have to suspend and manually kill it or it just hangs.
@fweep Are you also using guard-rspec?
I'm also experiencing this with guard-rspec.
Has anyone experienced this without guard-rspec?
Explain interrupt handling in the README. (Closes #404) [ci skip]