Gregory P. Smith <g...@krypto.org> 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 <rep...@bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to