This is probably the most common first use case someone has when trying to use subprocess for the first time and I think it has always been a bit of a wart that, given all the helpers and wrappers the subprocess module already has, it lacks one for that very obvious and common need.
Yes, run() covers everything, but so does subprocess.Popen() itself. Helpers still help. On Thu, Apr 4, 2019 at 1:15 PM Guido van Rossum <gu...@python.org> wrote: > Let’s please leave this alone. As Serhiy says run() covers everything. > > On Thu, Apr 4, 2019 at 3:03 AM Oleg Broytman <p...@phdru.name> wrote: > >> On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico < >> ros...@gmail.com> wrote: >> > On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith <n...@pobox.com> wrote: >> > > >> > > On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing < >> greg.ew...@canterbury.ac.nz> wrote: >> > > > >> > > > The check_output() function of the subprocess module raises an >> > > > exception if the process returns a non-zero exit status. This is >> > > > inconvenient for commands such as grep that use the return >> > > > status to indicate something other than success or failure. >> > > > >> > > > The check_call() function has a companion call(), but here is >> > > > currently no non-checking companion for check_call(). How >> > > > about adding one with a signature such as >> > > > >> > > > output(args) --> (status, output) >> > > >> > > Isn't this already available as: run(args, stdout=PIPE)? Is the object >> > > to the extra typing, or...? >> > > >> > >> > Or discoverability. If you want to run a subprocess and catch its >> > output, you'll naturally reach for check_output, and it feels clunkier >> > to have to use run() instead. >> > >> > +1 on adding a nice simple function, although I'm not 100% sold on the >> > name "output". >> >> get_output ? >> >> > ChrisA >> >> Oleg. >> -- >> Oleg Broytman https://phdru.name/ >> p...@phdru.name >> Programmers don't die, they just GOSUB without RETURN. >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspea...@redhat.com M: +1.336.210.5107 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
