3 ms·

Here's how to pipe two commands in Python: import subprocess subprocess.check_call("command1 | command2", shell=True) Depending on your use case ther

by d0mine 6y ago

Here's how to pipe two commands in Python: import subprocess subprocess.check_call("command1 | command2", shell=True) Depending on your use case there are other options e.g., fabric http://fabfile.org http://fabfile.org plumbum Use shell for what is really good for: concise DSL for running commands (one-liners). Leave complex logic (branches, explicit loops) for sane general purpose languages such as Python.

mikepurvis 6y ago
Right, and I do that, but it's an obvious hack; it causes a separate sh process to spawn, you open yourself to shell injection issues if you're not careful, teeing the pipe is trickier than it should be, etc etc.
- d0mine 6y ago
  you might have known this but the practice shows that It has to be repeated: there is no shell injection issues with literal string in your own code. YMMV but for those rare cases when I care about the shell injection, I just don't use shell and run the command directly in Python. Combination of shell one-liners and the main logic in Python works well in practice.
  - mikepurvis 6y ago
    Oh yeah, for sure. I think it's just frustrating having that one more piece of mental overhead. Like, it should be that there's one sane way to do all this stuff in Python. Instead it's literal blobs of shell in some cases, and subprocess.STDXX pipes linked up in other cases, and maybe sometimes you use shlex to sanitize your arguments, or you give up on streaming and just use communicate() to get the whole result in memory at once. Blah.
    - d0mine 6y ago
      I don’t see it as an overhead, I see using shell syntax as just another DSL like regex. There are many different use cases related to running processes—it is natural that different solutions may be preferred for different cases (check_{call,output}, with/out shell, run, Popen, pty/PIPE, threads/Asunción—all may be useful. And it is just stdlib ).

by d0mine 6y ago

mikepurvis 6y ago

Right, and I do that, but it's an obvious hack; it causes a separate sh process to spawn, you open yourself to shell injection issues if you're not careful, teeing the pipe is trickier than it should be, etc etc.

d0mine 6y ago
you might have known this but the practice shows that It has to be repeated: there is no shell injection issues with literal string in your own code. YMMV but for those rare cases when I care about the shell injection, I just don't use shell and run the command directly in Python. Combination of shell one-liners and the main logic in Python works well in practice.
- mikepurvis 6y ago
  Oh yeah, for sure. I think it's just frustrating having that one more piece of mental overhead. Like, it should be that there's one sane way to do all this stuff in Python. Instead it's literal blobs of shell in some cases, and subprocess.STDXX pipes linked up in other cases, and maybe sometimes you use shlex to sanitize your arguments, or you give up on streaming and just use communicate() to get the whole result in memory at once. Blah.
  - d0mine 6y ago
    I don’t see it as an overhead, I see using shell syntax as just another DSL like regex. There are many different use cases related to running processes—it is natural that different solutions may be preferred for different cases (check_{call,output}, with/out shell, run, Popen, pty/PIPE, threads/Asunción—all may be useful. And it is just stdlib ).