Add job control tests

[Tianyu (Ezri) Zhu]

We want a test that first starts an interactive command, e.g., try bash, and then run a few more commands and exit, to make sure that the summary function does not get sent to the background after the user's process finishes.

[Michael Greenberg]

expect is probably the right tool here.

[Konstantinos Kallas]

Do we want this in 0.2? I am adding it but we can remove it if we find that this requires significant work!

[Michael Greenberg]

I think it would be great to have, but I'm fine to push it off if it ends up being nasty.

It would be nice to not produce the error messages from set -m if we could avoid it: we can test [ -t 0 ] to see if STDIN is a terminal fd. If STDIN isn't a terminal, we need not set -m, since there won't be contention anyway. (We could even consider defaulting to not comitting if STDIN isn't a terminal, but then yes | try -- ... wouldn't work... and we should support that even if try -y is a better choice.)

[Konstantinos Kallas]

I think it would be great to have, but I'm fine to push it off if it ends up being nasty.

It would be nice to not produce the error messages from set -m if we could avoid it: we can test [ -t 0 ] to see if STDIN is a terminal fd. If STDIN isn't a terminal, we need not set -m, since there won't be contention anyway. (We could even consider defaulting to not comitting if STDIN isn't a terminal, but then yes | try -- ... wouldn't work... and we should support that even if try -y is a better choice.)

I am not sure I understand what this means. I added tests here (#79), do we want more for 0.2? If not, let's close this issue :)