Allow interaction with user before command is issued

[brandondrew]

Something I've often thought would be useful, when using commands I'm not intimately familiar with (or which have a bazillion options) is for the shell to be able to give feedback before I enter a command.

The most obvious, and probably most common, use for this would be giving information about command switches/options. If I'm using wget, for instance, if I type wget -m -k -p and then trigger feedback (either by a long pause, or a keystroke--whatever I've configured in .urchin_profile or whatever) I could get a brief one-line explanation of the last switch I entered, telling me that that causes wget to include related files like images and stylesheets and scripts related to the page being downloaded. This would be MUCH faster and easier for a user than opening a new terminal window and digging through a gigantic man page, or Googling, or testing the command and trying something else if it didn't work. Imagine if you had to lookup 10 different switches, which you could easily do with wget. Each might take a few seconds to try with this method, but might take a minute and a half each by Googling. That's 30 seconds versus 15 minutes. (The real value of speeding things up and smoothing them out is that you don't lose concentration, which is much more valuable than the time saved!)

Another example of how this could be used would be when sending commands to an ssh client. (Not ssh shell commands, but the commands you give the client after you type ~ to tell the client that what follows is not to be sent on the the machine you're connected to, but interpreted by the client itself.) Take a look at this question: http://serverfault.com/questions/435256/how-can-one-send-commands-to-the-inner-ssh-session/435262#435262 and imagine that you get feedback everytime you type ~ to tell you which machine's ssh client is going to receive the command.

What Urchin would provide would simply be a way of creating methods for intercepting and responding to incomplete commands, and a way of triggering the feedback. It would be a lot like command completion in bash or zsh in that some commands ship with the completions, and other times the user needs to write them, or find them on the web somewhere and install them. Urchin might initially include feedback methods for switches on a handful of commands, mostly as examples of how to write them, and to let people use them and see how they can be useful.

At some point some ambitious soul might do some metaprogramming to generate these feedback methods on the fly by parsing man pages. But that wouldn't be in the scope of the initial goals for this feature. Initially it's just about giving users a way to respond to not-yet-executed commands.

Perhaps like this (super-rough, off-the-top-of-my-head API example, probably terrible):

on_feedback_request_for /wget*-k/ do
  display_tip "Convert links for offline viewing"
end

on_feedback_request_for /rm -rf*/ do
  3.times { beep }
  display_tip "Whoooa!  Dude!  Think carefully!", { :box_color => :red, :text => yellow }
do

As far as I know this goes beyond what any other shell can do, and offers possibilities for interaction that don't exist in those other shells. (Or, if they are possible in the other shells, they almost certainly aren't easy to implement and certainly haven't been extensively taken advantage of. Zsh and bash command completion might possibly be capable of doing something like this, but not so easily.)

I can see this really making Urchin much more productive even for experienced shell users, as well as much more approachable for beginners.

[Spakman]

An interesting idea - thanks!

Would your first case be covered by fish-like tab-completion? I admit I haven't yet spent enough time with fish, but I really like some of the ideas. Assuming that stuff was generated, I wonder if any of that code can been incorporated into Urchin...

As for the SSH thing (I didn't know about the ~ stuff - cool!), I'm trying to think of some other use-cases - can you help? The idea definitely sounds cool, but I'm a little wary about adding too many things like hooks without a clear understanding of how they might be used (and also being sure that they will be used).

Note: this would probably be a tricky beast to implement. Sounds like it would involve some deep voodoo inside rb-readline.