[blacklight]

You could have probably created your own little wrapper on top of subprocess.Popen and dispatch stdout and stderr around. No need for an external library with bad tty/piping defaults just because it has a nice API (which needs to be tweaked with _tty_out=False anyway if i want to pipe the output to another command.

Btw does rich scrape the special formatting characters if piped?

[yeti-sh]

An example from the top of my head:

    compose = sh.docker.compose.bake('-f', 'deploy/dev.yml')
    …
    compose.down()
    …
    compose.up('--force-recreate', '-d')

I feel this is a major improvement on top of Makefiles + shell commands in them. Nice API _matters_; it is ergonomics and therefore productivity.

You can specify `_out=rich.print` and it will work but AFAIK it won't scrape ASCII terminal formatting characters.

I had to fix these characters in my `sh` based scripts but do not consider that as a big deal.

[theamk]

Doesn't the snippet above hide the errors and warnings (since I do not see any code to print them)?

Does not seem very ergonimic to me.

[yeti-sh]

No it does not, in fact; errors or warnings will pop up as an unhandled exception and print:

- command actually executed,

- snippet of stdout

- and snippet of stderr.

They can be handled using standard exception techniques.

[theamk]

Isn't that only for failed commands? so if command succeeds with warnings, or if if fails, but the retries and passed, ghen you get no output.

[yeti-sh]

The exception is raised if the command returns a non-zero error code. If it returns a zero error code then the return value of, say,

    compose.up()

contains the command's stdout.

In addition stdout can be redirected to a file, or to another command, or to a callable, ­— which will be called for chunks of stdout while the command is in operation.