Support providing text input to commands

[paulproteus]

Hi nice cram people,

I seem to have written a different, similar tool, and I think probably I should contribute to cram instead. You can find my tool here: https://github.com/sandstorm-io/sandstorm/tree/master/installer-tests

One feature my tool has is that I can provide text input to an interactive process. You can see an example here: The $[type] directive means "Type the empty string, then press enter"

https://github.com/sandstorm-io/sandstorm/blob/master/installer-tests/full-server-install-on-jessie-with-broken-hostname.t#L28

So I would like it if cram supported providing text input to programs. I can possibly work on implementing this if it's something that y'all would merge.

Let me know what you think!

[aiiie]

Apologies for the absurdly late reply.

Would piping input to stdin not be equivalent?

[paulproteus]

Hi @Brodie !

Piping input to stdin would do the job; however, I personally wanted a way to combine program input and output for (IMHO) a more readable test.

Here's one example:

https://github.com/sandstorm-io/sandstorm/blob/master/installer-tests/interactive-dev-install.t#L9

$[slow]How are you going to use this Sandstorm install? [1]$[type]2

On this line, the program prints

How are you going to use this Sandstorm install? [1]

and the test user types this string plus a newline:

2

This isn't the only input the program takes -- later, the test user presses enter.

That's not a super interactive example, but anyway, that's the idea of $[type].

(BTW, $[slow] means that it's OK to wait extra long for a particular line of output.)

There's one case in which piping input to stdin would not be equivalent. The script under test treats EOF to mean "accept the default", but EOF won't really happen for normal interactive use; therefore, the $[type] followed by nothing indicates that this is a line where input is expected.

I'm not sure that my design decisions with $[type] are good per se, but I figured I'd answer your question about them.

Other than EOF treatment, and the fact that you can see the expected input alongside the output that comes before it in time, I think piping to stdin would be equivalent to $[type]. Some programs operate differently if stdin is/isn't a TTY/PTY, but https://github.com/sandstorm-io/sandstorm/blob/master/install.sh (my original program under test) does not.