Re: subprocess pipe

[Camille Harang]

Hi Chris, thanks for your reply.

Chris Rebert a écrit :
> Quoting http://docs.python.org/library/subprocess.html , emphasis mine:
> """
> On Unix, with shell=True: [...] If args is a sequence, ***the first
> item*** specifies the command string, and any additional items will be
> treated as additional arguments ***to the shell itself***.
> """

Yes, I read that, that's why I'd like to avoid shell=True, but if I do
shall=False subprocess.Popen is no longer able to catch the standard
inputs & outputs of pg_dump (but it does on other commands that has a
prompt, e.g. 'passwd')

That's the problem :-/

Regards,

Camille.

-- 
The Good, the Bad and the Ugly under Creative Commons!
https://yk.net/r/lp1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess pipe

[Camille Harang]

Tim Harig a écrit :
> On 2010-11-14, Camille Harang  wrote:
>> # pg_dump prompts for password so I inject it in stdin.
>> pgsql.stdin.write('MY_PASSWORD' + '\n')
> 
> For security reasons, some programs use direct access to the TTY system
> for password entry rather then reading from stdin.  Most of these programs
> provide another access mechanism that can be used for authentication
> (ie public keys or storing the password in a permission restricted
> configuration file.

Ha, indeed, I suspected that pg_dump didn't behave normally, security
matters might be an explanation, I'll dig in that way, thanks a lot.

Regards,

Camille.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: subprocess pipe

[Camille Harang]

Tim Harig a écrit :
> On 2010-11-14, Camille Harang  wrote:
>> # pg_dump prompts for password so I inject it in stdin.
>> pgsql.stdin.write('MY_PASSWORD' + '\n')
> 
> For security reasons, some programs use direct access to the TTY system
> for password entry rather then reading from stdin.  Most of these programs
> provide another access mechanism that can be used for authentication
> (ie public keys or storing the password in a permission restricted
> configuration file.

Ha, indeed, I suspected that pg_dump didn't behave normally, security
matters might be an explanation, I'll dig in that way, thanks a lot.

Regards,

Camille.
-- 
http://mail.python.org/mailman/listinfo/python-list

subprocess pipe

[Camille Harang]

Hi all,

I'm having a problem with subprocess.Popen. It seems that its unable to
capture the pg_dump's standard inputs & outputs in a non-shell mode:

from subprocess import Popen, PIPE

# fire pg_dump in order to read data from the file object pgsql.stdout
pgsql = Popen(['/usr/bin/pg_dump',
   '--host', 'localhost',
   '--password',
   '--username',
   'mammique'],
  stdin=PIPE,
  stderr=PIPE,
  stdout=PIPE,
  shell=True)

# pg_dump prompts for password so I inject it in stdin.
pgsql.stdin.write('MY_PASSWORD' + '\n')

In the shell mode (shell=True) pipes works but the args (username, etc.)
are omitted. If I turn to shell=False the arguments are passed to
pg_dump but subprocess.Popen is no longer able to capture the standard
inputs & outputs, the password prompt appears on the TTY instead and
doesn't take the input written in stdin. It seems that subprocess.Popen
has only this problem with pg_dump, other interactive command lines
seems to be correctly handled.

Any lead?

Thanks,

Camille.

-- 
http://mail.python.org/mailman/listinfo/python-list