ShellStream, end of command / waiting for input

Jun 5, 2014 at 9:38 PM
Edited Jun 5, 2014 at 9:39 PM
Hi all, this project is the backbone to some pretty nice automation tools on our end, so thanks very much.

One thing I do is interact with a shell-within-a-shell program - think irb or python shell on Unix system. I have APIs which emulate sending commands and receiving response from this shell as well as from the Unix prompt.

Is there a clean way to detect the state in the ShellStream which indicates the shell is waiting for user input, whether it's the Unix prompt or other (irb/Python, or even a custom ANSI menu app)? Even just a solution for the Unix prompt would be very useful.

A trivial example would be a Unix shell with a dynamic prompt, say it contains the current working directory name. I can figure out what the prompt is initially, and train the API to expect it as the 'last' output from the stream, but if I cd somewhere it throws everything off. I can use a special 'cd' API to re-detect the new prompt but that's an additional delay to read the stream for the new prompt (and not too clean a solution).

e.g.

string prompt = my_api.detect_prompt();
my_api.send_command("ls -lp\r");
string output1 = my_api.read_until_encounter(prompt); // read until we encounter the prompt string

my_api.send_command("cd /tmp/my_directory\r");
prompt = my_api.detect_prompt(); // re-learn prompt because it changed from /home/user> to /tmp/my_directory>

my_api.send_command("ls -lp\r");
string output2 = my_api.read_until_encounter(prompt);

replaced by

my_api.send_command("cd /tmp/my_dir\r");
string output 3 = my_api.read_everything(); // smart enough to identify EOF equivalent
Jul 16, 2014 at 4:59 PM
@washirv,

The short answer is "Yes." You can look for a prompt, and/or apply a timeout. You can even extend and write your own, which others have done.

Many have posted working examples in these discussion groups, and you can even look at (or compile if you like) the source code tests (something I never do when I write, I'm ashamed to say), which you can find here.

As you can see by the source, it is an extremely large and comprehensive effort, and one with an interesting history. When you get something working well, please think about posting it in the discussions. Who knows? It might make it into some more formal docs in future! :)

pat
:)