Incodentally, I think your example is wrong. It should be either psql >/dev/null 2>&1 or psql &>/dev/null Notice the reversal of redirects in the first one. Of course, this doesn't change anything about the core discussion... - C On 1/24/08, Isaac Morland <ijmorlan@cs.uwaterloo.ca> wrote:
On Thu, 24 Jan 2008, skip@pobox.com wrote:
Mike> 2. Is this really the hard-coded behavior we want? I don't think Mike> my use-case is that odd; in fact, what I find very odd is that Mike> the prompt output is send to stderr. I mean, I'm printing the Mike> prompt for a question, not some error message. Can there not at Mike> least be an optional parameter to indicate that you want the Mike> output sent to stdout rather than stderr?
I can think of situations where you don't want the output to go to stdout either (suppose it's the regular output of the file you want to save to a file). Having a choice seems the best route.
What about an option (maybe even a default) to send the prompt to stdin?
The Postgres command line interface psql appears to do this:
$ psql 2>&1 >/dev/null Password: $
(I typed my password and then I quit by typing ^D; if I type the wrong password, it looks the same on screen but it quits right away without waiting for ^D)
I think ssh also does this when it needs to prompt for a password.
Really the prompt is part of the input, not part of the output, in a certain sense. Have people actually verified that the prompt is really sent to stderr right now by using 2>/dev/null to attempt to suppress it?
Isaac Morland CSCF Web Guru DC 2554C, x36650 WWW Software Specialist _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/shiblon%40gmail.com
-- Sent from Gmail for mobile | mobile.google.com