Ninja's console pool has a few different behaviors:
it has direct access to the TTY which means it
can access stdin
it can print terminal escape codes
if the command detects it has TTY access, it might vary its output to use escape codes
because Ninja gives TTY control to the command, Ninja no longer prints its own status updates while the command is running
it has depth=1, only one console-tagged step can run at once
Currently:
n2 only implements part 3.
I am skeptical any Ninja users(?) depend on 1.i.
I think the implementation options here are either to do what Ninja does, which means giving direct console access and suppressing n2 status updates...
...or maybe try something fancy involving running the process with a pseudo tty (to make it believe 1.iii) and still rendering its progress live.
I think to do that we'd need to implement some terminal emulation behavior, but I expect there are two vague categories of tools here: the ones that just do some simple color printing and line overprinting, or the ones that go wild with complex screen updates. I think we could plausibly implement enough terminal emulation to handle the former and then bail to just letting the command run solo if we encounter any unexpected terminal escape codes. It's plausible to me that no commands actually depend on the latter. (Writing terminal emulators is a hobby of mine, maybe I am just too eager here...)
Ninja's
consolepool has a few different behaviors:Currently:
I think the implementation options here are either to do what Ninja does, which means giving direct console access and suppressing n2 status updates...
...or maybe try something fancy involving running the process with a pseudo tty (to make it believe 1.iii) and still rendering its progress live.
I think to do that we'd need to implement some terminal emulation behavior, but I expect there are two vague categories of tools here: the ones that just do some simple color printing and line overprinting, or the ones that go wild with complex screen updates. I think we could plausibly implement enough terminal emulation to handle the former and then bail to just letting the command run solo if we encounter any unexpected terminal escape codes. It's plausible to me that no commands actually depend on the latter. (Writing terminal emulators is a hobby of mine, maybe I am just too eager here...)
Forked from discussion in #68.