-On [20080129 00:13], Greg Ewing ([EMAIL PROTECTED]) wrote:
>What document did this come from? This sounds more like it's
>talking about what should be described in various sections of
>a man page, not what should be written to the various streams
>by a program.
It did, it's from the C. Rationale
Jeroen Ruigrok van der Werven wrote:
> I cannot find anything explicitly in favour of or against this in POSIX. The
> stuff quoted below is what I could find.
>
> "3.105 Command Language Interpreter
>
> STDERR
>
> This section does not describe error messages that refer to incorrect
> operation
Guido van Rossum wrote:
> On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>So it appears that the official Unix Way prefers using stderr
>>over stdout for prompting, if using the std files for it at all.
>
> That's a dangerous generalization from just one example. I'd prefer it
> While I couldn't locate such a document, it makes sense when you
> consider that if such a process is part of a pipeline you really don't
> want the prompts being handled as input by the downstream processes.
>
> That's why mv and similar utilities prompt on standard error.
No, that doesn't r
-On [20080128 19:51], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote:
>I cannot find anything explicitly in favour of or against this in POSIX. The
>stuff quoted below is what I could find. I do not think there's a hard
>mandate either way, but from my experience of having been a committer
On Jan 28, 2008 11:17 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> > That's a dangerous generalization from just one example. I'd prefer it
> > if you could unearth some POSIX or Linux base document saying this.
> >
> While I couldn't locate such a document, it makes sense when you
> consider that
Guido van Rossum wrote:
> On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Isaac Morland wrote:
>>
>>> 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
>>> P
-On [20080128 18:57], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> So it appears that the official Unix Way prefers using stderr
>> over stdout for prompting, if using the std files for it at all.
>
>That's a dangerous generalizatio
On Jan 28, 2008 12:35 AM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Isaac Morland wrote:
>
> > 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:
> > $
>
> No, it's
Isaac Morland wrote:
> 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:
> $
No, it's probably using the C stdlib routine getpass(). From the man
page:
The getpa
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 <[EMAIL PROTECTED]> wrote:
> On T
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>> It's entirely likely that the difference in what I am seeing and what
>> you guys are seeing is caused by my not having GNU readline
>> installed. Nevertheless, the behavior without it seems wrong, and is
>> certainl
Guido van Rossum python.org> writes:
>
> > It's entirely likely that the difference in what I am seeing and what you
> > guys
> > are seeing is caused by my not having GNU readline installed. Nevertheless,
> > the behavior without it seems wrong, and is certainly different from the
> > documenta
On Jan 24, 2008 11:41 AM, Mike Kent <[EMAIL PROTECTED]> wrote:
> pobox.com> writes:
>
> >
> >
> > Isaac> Have people actually verified that the prompt is really sent to
> > Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
> >
> > Good point. On my machine at work (
pobox.com> writes:
>
>
> Isaac> Have people actually verified that the prompt is really sent to
> Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
>
> Good point. On my machine at work (Solaris), Python 2.4 seems to send its
> raw_input prompt to stdout, not st
Beware: this may depend on whether GNU readline is enabled or not --
under many circumstances, raw_input() calls GNU readline instead of
using sys.stdin/stdout.
I do agree that if there are any conditions where it uses stderr
instead of stdout those are mistakes.
On Jan 24, 2008 9:47 AM, <[EMAIL
Isaac> Have people actually verified that the prompt is really sent to
Isaac> stderr right now by using 2>/dev/null to attempt to suppress it?
Good point. On my machine at work (Solaris), Python 2.4 seems to send its
raw_input prompt to stdout, not stderr:
% python
Python 2.4.2
On Thu, Jan 24, 2008 at 12:36:51PM -0500, Isaac Morland wrote:
> 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
On Thu, 24 Jan 2008, [EMAIL PROTECTED] 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
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
Recently I was trying to debug an old python program who's maintenance I
inherited. I was using the quick-and-dirty method of putting some 'print
>>sys.stderr' statements in the code, and then running the command with
'2>filename' appended to the end of the command line. Imagine my surprise
to se
21 matches
Mail list logo
