[issue24919] Use user shell in subprocess

[Jan Studený]

New submission from Jan Studený:

According to POSIX specification the pathname of user shell is stored in SHELL 
(environmental variable, see 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08) 
so I think that is good idea to use that pathname instead of hardcoded one.
Change is only in one line of subprocess package to use SHELL environmental 
variable and use hardcoded shell pathname as fallback.

lines 1431-1433
```
if shell:
args = ["/bin/sh", "-c"] + args
if executable:
```

to

```
if shell:
args = [os.environ.get("SHELL","/bin/sh"), "-c"] + args
if executable:
```

--
components: Library (Lib)
messages: 249023
nosy: Jan Studený
priority: normal
severity: normal
status: open
title: Use user shell in subprocess
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24919] Use user shell in subprocess

[R. David Murray]

R. David Murray added the comment:

Thanks for the suggestion, but that would make programs using subprocess 
non-portable.  There is an open issue to use the *default* shell instead of 
hard coding it (because the sh-alike is not at /bin/sh on, eg, Android), but 
using the user shell would break lots of programs.  Your suggestion was brought 
up by a core dev (and rejected) in that issue (issue 16255)

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> subrocess.Popen needs /bin/sh but Android only has 
/system/bin/sh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24919] Use user shell in subprocess

[eryksun]

eryksun added the comment:

I expect Popen's shell=True option to use the same shell as os.system.  The 
POSIX spec for the [system function][1] requires running sh, as follows:

execl(, "sh", "-c", command, (char *)0);

glibc uses "/bin/sh" for the shell path. Modifying the SHELL environment 
variable doesn't affect the behavior of os.system. I would be surprised if 
Popen's shell=True had been designed like that. Thankfully it's too late to 
change this since it could break existing code. ;-)

The story is different on Windows. The CRT's system() prefers the shell that's 
set in the ComSpec environment variable. So on Windows Popen uses 
os.environ.get("COMSPEC", "cmd.exe").

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24919] Use user shell in subprocess

[eryksun]

eryksun added the comment:

Here's the rationale given for ignoring SHELL in POSIX system():

One reviewer suggested that an implementation of system() might
want to use an environment variable such as SHELL to determine
which command interpreter to use. The supposed implementation
would use the default command interpreter if the one specified
by the environment variable was not available. This would allow
a user, when using an application that prompts for command lines
to be processed using system(), to specify a different command
interpreter. Such an implementation is discouraged. If the
alternate command interpreter did not follow the command line
syntax specified in the Shell and Utilities volume of
POSIX.1-2008, then changing SHELL would render system()
non-conforming. This would affect applications that expected the
specified behavior from system(), and since the Shell and
Utilities volume of POSIX.1-2008 does not mention that SHELL
affects system(), the application would not know that it needed
to unset SHELL.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com