New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subprocess.pipe function #47798
Comments
Attached is a patch that add "pipe" command to the "subprocess" module. pipe(["ls"], ["grep", "test_"]) will return the output of |
Not sure about the name, maybe "chain" will be better? |
Hello, I was searching for a bug in subprocess I was implementing the exact same functionality Feel free to use it |
Here's a clean version with doc & test enjoy ! |
|
Vincent, |
On Mon, Sep 1, 2008 at 5:13 PM, Amaury Forgeot d'Arc
This is not a patch against python, this is a standalone script, just But thanks for the input anyways. If this functionality is really interesting people and agreed to be integrated |
I've written a package which can do this with arbitrary redirection in all subcommands (and some more). You can, for example, do this: >>> Pipe(Sh('echo -n foo >&2', {2: 1}), Sh('cat; echo ERROR >&2', {2: os.devnull})).capture(1).read()
'foo' The package is at: http://github.com/aht/pc.py |
pipe.patch looks interesting to me. I would replace **kwargs with a keyword-only argument named stderr, since that’s the only key used. This requires more tests and docs. |
I think this would be more useful if you could pass an optional input string (as in communicate()) and if it returned a (stdout, stderr) tuple. Or perhaps even a (return code, stdout, stderr) tuple; alternately, non-zero return codes could raise an exception. |
I just found this open issue and I can work on it. What is left to do before closing it? |
Thanks for being willing to work on it. If what is wanted is a way to pipeline shell commands, Python already has that functionality in the pipes module. So the interesting thing here would be pipelining *non* shell commands, to avoid the shell exploits that using a shell pipeline invites. The pipes module already has a worked out API, so perhaps it would be useful to see about re-implementing pipe's command execution using subprocess, and expand the API to allow for argv style command specification that would be fed to subprocess using the default shell=False. This would also presumably allow pipes to be used when there's no bash shell available. The downside is that we might break current uses of pipes if we replace the shell version of the pipelining with subprocess shell=True, while using subprocess only if the command specifications are argv lists would result in code with a split personality. But if I were working on it I'd experiment with that approach to see if it made sense. Other core devs may have other opinions on this :) |
Let me check whether I understood you suggestion... What you are saying is that it is already possible to pipeline shell commands through subprocess, such as in the following line? subprocess.call('ls -l | grep Music', shell=True) However, this requires the command to be executed in a shell environment. Hence, it would be a good idea to extend it to non-shell command execution. Is this right? |
No, I'm talking about https://docs.python.org/3/library/pipes.html |
Oh, I see... The pipes module uses os.system and os.popen to execute commands under a "/bin/sh" environment. So you are proposing to re-implement it with subprocess in order to execute commands without shell and, also, extend by accepting argv-style parameters. Is this right this time? How would an argv-style pipe look like? |
Exactly like the string pipes API, but cmd would be a list of arguments instead of a string. That would then become the argument list to the subprocess stage. It is an interesting question whether we'd want to allow mixing stage types. I'd say no (at least initially, if people complain we can add it as a feature later, but we can't subtract it if we implement it now and decide it is a bad idea after putting it in the field). Now, keep in mind that you've only got my opinion so far that this is even a good idea :) |
Sure. I'll leave this issue for a while before others can emit their opinions. |
this would have been nice to have more than once in my personal projects, and in build/infra tooling for Chromium OS. our alternatives so far have been the obvious ones: use subprocess.run to capture & return the output, then manually feed that as the input to the next command, and so on. we know it has obvious overhead so we've avoided with large output. we strongly discourage/ban attempts to write shell code, so the vast majority of our commands are argv style (list of strings), so the pipes module wouldn't help us. handling of SIGPIPE tends to be where things get tricky. that'll have to be handled by the API explicitly i think. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: