Gregory P. Smith <[email protected]> added the comment:
The shell was isolating the user from the exec error by always existing and
turning the exec error into a status return.
>>> subprocess.run('foo', shell=True)
/bin/sh: line 1: foo: command not found
CompletedProcess(args='foo', returncode=127)
>>> subprocess.getstatusoutput('foo')
(127, '/bin/sh: line 1: foo: command not found')
For things that don't actually _need_ the output as a pipe file (such as your
.read() example), I recommend using .run() like that today and accessing the
.stdout and .returncode attributes of the CompletedProcess. Or use the old
getstatusoutput() API if you don't mind stderr being included.
As far as new APIs go, yet another keyword only argument to subprocess.POpen's
existing huge list that tells it to turn exec failures into a particular
returncode value could be added as a feature. Is this use case compelling
enough to do that?
...
As far as distinguishing failures go, I suggest making such an API be to allow
the user to specify a non-negative int to use as returncode - a unique int or
one that is out of range such as a negative number or large number could be
used to distinguish things if the user were so inclined or even an int subclass
like True or an IntEnum value. But lets keep it a non-negative int, not an
arbitrary object. Negative ints map to signals; using those would be confusing
for CalledProcessError when a check constructs one.
```
>>> subprocess.run('foo', exec_fails_via_returncode=256)
CompletedProcess(args='foo', returncode=256)
```
With a default of exec_fails_via_returncode=None being the existing exception
raising behavior.
That isn't joyful to use as an API. So I don't expect most people would use it
directly. They'd have a wrapper function. Ie: just another variation on
getstatusoutput() that allows for use of a shell or stderr inclusion to be
controlled.
The shell is fast. I'd just use the shell when replacing os.popen uses in
tests.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue42648>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
