LMlmm·Aug 17, 2016
What you actually do in Python is use https://github.com/kennethreitz/envoy
In “It's The Future”not-kennethreitz
envoy
Python2012–2016
not-kennethreitz / envoy · Archived
envoy
Python Subprocesses for Humans™.
14Distinct people
14Mentions
0Explicit recommenders
2.3KGitHub stars
What to know before exploring
What it is
Python Subprocesses for Humans™.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2012-01-03 16:31:18 UTC to 2016-08-17 14:31:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
14 sources> Right now it's possible, but in a long-winded way
How is it long-winded? Basic operations such as cd, ls, etc., all work inside IPython.
Also, try envoy[0] for subprocesses.
https://github.com/kennethreitz/envoy
In What is new in IPython 1.0See https://github.com/kennethreitz/envoy
Example:
>> r = envoy.run('uptime | pbcopy')
In Why Awk for AI? (1997)Python scripting is an investment, eventually it becomes as frictionless as bash scripting. Especially if you have a good shell scripting library.
I usually use Fabric, SaltStack, or https://github.com/kennethreitz/envoy
In Unix Text Processing (1987)From a quick look at the code, it's not supported on windows because of its reliance on terminal utilities(pty, termios).
Thanks! Like I said, I don't have lots of experience with Python, so this is very valuable info for me :)
Doesn't the banner state to use the previous version(pbs) for windows support?
Yes, but the PyPi page for pbs 0.110 states: "PBS will no longer be supported." I'm not comfortable with basing my code on a library which won't be supported in the future.
And if for some reason it still doesn't work out, you can always use subprocess(which this library is using anyway) or https://github.com/kennethreitz/envoy
I didn't know about envoy either. Thanks again! :)
EDIT: Upon closer examination, the whole OProc class depends on os.fork(), which is available only on Unix, according to Python docs.
In Python Libraries you should know about> I'm considering that, but I still haven't managed to understand just why it isn't supported on Windows.
From a quick look at the code, it's not supported on windows because of its reliance on terminal utilities(pty, termios). Doesn't the banner state to use the previous version(pbs) for windows support?
https://github.com/amoffat/sh/blob/master/sh.py#L33
And if for some reason it still doesn't work out, you can always use subprocess(which this library is using anyway) or https://github.com/kennethreitz/envoy
In Python Libraries you should know aboutCould somebody explain to me how this is different from envoy? https://github.com/kennethreitz/envoy
Not meant as a snide remark; genuinely curious.
In Sh.pyAs someone who to this day still cringes every time they need to work with the subprocess module, do yourself a favor and use Kenneth Reitz's excellent wrapper library called Envoy:
https://github.com/kennethreitz/envoy
For reference, he's the same guy that did the Requests module, which is pretty much the defacto standard for avoiding urllib hell.
In Working with Python subprocessThis module is a huge hack. It's a neat hack, though :)
I've written what I feel is a much better solution to this problem: Envoy.
https://github.com/kennethreitz/envoy
It's pythonic and makes far fewer assumptions about both your code and what you're running.
In Fixing the Python subprocess interfaceWow this is so frighteningly magical and will break in many entertaining ways.
For a sane alternative I'd recommend Kenneth Reitz' awesome Envoy (https://github.com/kennethreitz/envoy)
In Fixing the Python subprocess interfaceI like Kenneth Reitz's envoy too. He describes it as "Python Subprocesses for Humans™", similar to how he describes Requests, which he also wrote.
https://github.com/kennethreitz/envoy
In Fixing the Python subprocess interfaceFWIW, re-replaying the stack trace to figure out what was imported and re-implementing it is a horrible idea. There are much better ways to do this type of import voodoo, specifically the import hooks that Python ships with. Here's an example of their use inside a small side project of mine: https://github.com/tswicegood/maxixe/blob/master/maxixe/__in...
All that said, this is horribly un-Pythonic. A much better route to so is something like envoy[1] which simply wraps `subprocess` in a sane API.
[1]: https://github.com/kennethreitz/envoy
In Fixing the Python subprocess interfaceIt's funny you mention that. The author/speaker wrote a "Subprocesses for humans" module, too: https://github.com/kennethreitz/envoy
There's no fundamental problem that's stopped Python from doing this before. For some reason, all of the ways to spawn a subprocess in Python have tried to map almost directly to the underlying C API... which is pretty awful.
In Python for HumansI was intrigued by the author's library "envoy", which is intended to provide a more intuitive interface to running processes from python. (https://github.com/kennethreitz/envoy)
The back story is that the older APIs that Python comes with -- os.popen and os.system -- are deprecated. Programmers are urged to use the "subprocess" module instead. Although this doesn't have the problems of the original functions, it has a rather arcane interface, in particular if you want to read the output (stdout or stderr) of a subprocess.
"envoy" seems to aim at fixing this, by providing sane defaults and being optimized for the common case. However, these defaults have drawbacks of their own.
1. envoy defaults to keeping the process output in memory, as a giant string. This can be a bad choice with regard to memory usage and performance.
2. You can run
Read the rest
several processes in a pipe using ("cat foo | grep bla"). But otherwise as far as I can see, run() ignores regular Shell semantics, such as quotes. I imagine this can lead to unexpected results. The amount of data passed from one process to the next is capped at 10 MB -- recipe for bugs that are hard to find.
3. subprocess.call() accepts an array in the style of ["ls", "-l", "/mnt/My SD card"]. This has obvious advantages over having to deal with escaping shell characters. A good API should preserve this advantage over os.system().
4. The defaults cannot be overridden, and no preperations have been made to allow changing them. Of course this can be changed in the future. However, one of the reasons the subprocess.* API is convoluted is that it allows all kinds of flexibility, much of which is needed in many serious programs. It may be difficult to add this flexibility to envoy at a later stage. The point is that a flexible API is hard.
None of this is to discourage this initiative, which seems to me a much-needed improvement over Python's built-in API. Also, with a version number as low as 0.0.2, there is probably little need to worry about API compatibility.