3 ms·

I like sh for brevity of its API. I often have to use `_tty_out=False`, but this is easy to fix once and for all commands in a script: my_sh = sh.bake(_tty

I like sh for brevity of its API. I often have to use `_tty_out=False`, but this is easy to fix once and for all commands in a script: my_sh = sh.bake(_tty_out=False) my_sh.do_whatever() The way how sh captures output can apparently be altered, say, by providing a callable to _out argument.

blacklight 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        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 3y ago
        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.

blacklight 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        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.