fix: enhance shell() to know when it is interactive

[michaelneale]

This will either return to user and ask them to run it themselves, or ask for more information, or work out how to run it with the information it has. Uses patterns and the accelerator model to supervise command output

fixes: #49

How this works:

• Watches stdout and stderr
• looks for patterns which may indicate it is blocking for user response
• If there is will return to the user or ask for more input (no blocking)
• If the process doesn't return any output for a time, it examines the log with the acclerator model to see if it may be a long running process and confirm with the user.

For example, both of these are interactive commands now handled:

The former one uses the accelerator model to detect if it is long running or not. Former uses a pattern to detect.
Can also log stdout etc now (if we wanted a mode for that) - but you can just ask goose to show you

[Kvadratni]

Yes please

[lukealvoeiro]

This looks good, though I haven't tested it myself since I'm reviewing after hours.

[lukealvoeiro]

Curious how this handles cases where log lines are replaced (e.g. print(..., end="\r"). This may be handled differently in stdout vs in a terminal console, but figured I'd float it as something to double check before merging.

[michaelneale]

hrm - might be worth trying out

[michaelneale]

I believe would timeout and then consider if it should continue or not

[michaelneale]

BTW have been using this all week and has been really great

[baxen]

This is super cool, great idea. I think we need to refactor how the subprocess is handled in the threads: if i'm understanding correctly, if the prompt is slow to show up i think we'll go through all the checks before anything is visible. That probably doesn't happen often - most prompts for input start immediately - but would like to take a pass to cover it

[michaelneale]

@baxen great - not sure if it really matters as a timeout would be triggered but wouldn't necessarily fail (but not sure how to confirm) - the accelerator would then decide or not if to continue (that could probably be enhanced?). There probably could be improvements so it isn't blocking on readline (in case there is no line feeds) and handling things that done return line by line perhaps, but overall, I haven't seen any specific failure modes that made it troublesome for me so far (would want to test it with some hefy tasks, like installs etc).

[baxen]

We discussed a bit about the tradeoff between this occasionally being wrong - if the check model incorrectly identifies the command as stuck, it could interrupt something that was otherwise working. But this appears rare from testing, and seems worth it to catch the more common issue of running a web service