Peter E. can you look at this?  I see simple prompt doing:

        fputs(prompt, stdout);

which I think should be stderr.  Peter, can you check on those?


> 
> Does it still make sense to send the following to
> pgsql-bugs@postgresql.org?
>   
> - Scott Williams
> 
> 
> Subject: pg_dump -u prompts for username/password on stdout rather than stderr
> ----------------------------------------------------------------------
> Your name		:	Scott Williams
> Your email address	:	Scott@James.com
> 
> 
> System Configuration
> ---------------------
>   Architecture (example: Intel Pentium)  	: i586
>   Operating System (example: Linux 2.0.26 ELF) 	: Linux 2.2.10
>   PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3 
>   Compiler used (example:  gcc 2.8.0)		: egcs-2.91.66 19990314 (egcs-1.1.2 release)
> 
> 
> Please enter a FULL description of your problem:
> ------------------------------------------------
> 
>   When running pg_dump with the -u switch, it prompts me on stdout for
>   the username and password, rather than stderr.  Unfortunately this
>   causes a bit of confusion when doing
> 
>      pg_dump -o -u some_db >dump_file
> 
>   since it puts the prompt in the dump_file rather than to the screen,
>   making dump_file syntacticly invalid.  Of course the work around is
>   to use the `-f' flag.  However, redirecting pg_dump's stdout to a
>   file using `>' is what's shown under `Usage' in the pg_dump chapter
>   of the `PostgreSQL User's Guide'
> 
> 
> Please describe a way to repeat the problem.   Please try to provide a
> concise reproducible example, if at all possible: 
> ----------------------------------------------------------------------
> 
> If you know how this problem might be fixed, list the solution below:
> ---------------------------------------------------------------------
> 
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 16 Feb 2000 18:36:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
psql password prompt

I was noticing that psql now exits on ctrl-C. This is much
better than the previous behaviour where it kinda got
muddled up and you could destroy your database if
a half-completed command was in its buffer.

But wouldn't it be better if it was like /bin/sh and
popped you back to a fresh prompt or something?

Thu, 17 Feb 2000 13:39:10 +1100
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
psql problem
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> I was noticing that psql now exits on ctrl-C.

Ugh.  So now, if you type control-C while a query is in progress,
you get a cancel request sent, as you intended.  Type it a tenth of
a second too late, however, and you get booted out of psql instead.

I think this is lousy human engineering, even though I'm sure Peter
thought it was a good idea at the time.  If we trap control-C we
should trap it all the time, not create a delay-dependent behavior.

> This is much better than the previous behaviour where it kinda got
> muddled up and you could destroy your database if a half-completed
> command was in its buffer.

What?  Are you saying that control-C doesn't do a \r (reset the
query buffer)?  That's probably true, and I agree that it should...

			regards, tom lane

Wed, 16 Feb 2000 22:30:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql problem 
> 
> I was noticing that psql now exits on ctrl-C. This is much
> better than the previous behaviour where it kinda got
> muddled up and you could destroy your database if
> a half-completed command was in its buffer.

Yes, ^C exits if you are at a prompt, and terminates the current query
if you are running one. Very nice.

> But wouldn't it be better if it was like /bin/sh and
> popped you back to a fresh prompt or something?

You mean reprinted the prompt?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 16 Feb 2000 22:34:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] psql problem]
> Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > I was noticing that psql now exits on ctrl-C.
> 
> Ugh.  So now, if you type control-C while a query is in progress,
> you get a cancel request sent, as you intended.  Type it a tenth of
> a second too late, however, and you get booted out of psql instead.
> 
> I think this is lousy human engineering, even though I'm sure Peter
> thought it was a good idea at the time.  If we trap control-C we
> should trap it all the time, not create a delay-dependent behavior.

Yes, I figured that would be an issue.  Not sure if I like it or not. 
Of course, ^D exits you if you are not in a query.

> 
> > This is much better than the previous behaviour where it kinda got
> > muddled up and you could destroy your database if a half-completed
> > command was in its buffer.
> 
> What?  Are you saying that control-C doesn't do a \r (reset the
> query buffer)?  That's probably true, and I agree that it should...


Looks like it works fine:

	test=> select * from pg_class, pg_proc;
	^C
	Cancel request sent
	ERROR:  Query was cancelled.
	test=> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 16 Feb 2000 22:36:22 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] psql problem
>> What?  Are you saying that control-C doesn't do a \r (reset the
>> query buffer)?  That's probably true, and I agree that it should...

> Looks like it works fine:

> 	test=> select * from pg_class, pg_proc;
> 	^C
> 	Cancel request sent
> 	ERROR:  Query was cancelled.
> 	test=> 

No, I think Chris was complaining about the behavior with an
incomplete query in the buffer.  I can't show it with current
sources since psql is exiting on ^C, but 6.5 works like this:


play=> foobar
play-> ^C
CANCEL request sent
                        <-- return typed here to get a prompt
play-> select 2+2;
ERROR:  parser: parse error at or near "foobar"
play=>


Notice the prompt correctly shows that I still have stuff in the
query buffer after ^C.  I think Chris is saying that ^C should
flush the buffer like \r does ... and I agree.

			regards, tom lane

Wed, 16 Feb 2000 23:02:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql problem 

There are two issues. One is what happens when there is something
in the buffer and I hit ^C. Intuitively I think I should get back to 
a "sane" state ready for a new query. I mean I start off typing
a long query, then I change my mind I want ^C to get me a
clear prompt.

What used to happen is it says "CANCEL request sent". Then I
think "ok I'll put in a different query". but that doesn't work.
Maybe \r was the correct command but I never took the time
to learn that.

The other issue is what happens if I'm just at a prompt, I don't
think it should exit on ^C. Basicly this is because I'm familiar
with the way /bin/sh works and I wish psql had the same semantics.

Tom Lane wrote:
> 
> >> What?  Are you saying that control-C doesn't do a \r (reset the
> >> query buffer)?  That's probably true, and I agree that it should...
> 
> > Looks like it works fine:
> 
> >       test=> select * from pg_class, pg_proc;
> >       ^C
> >       Cancel request sent
> >       ERROR:  Query was cancelled.
> >       test=>
> 
> No, I think Chris was complaining about the behavior with an
> incomplete query in the buffer.  I can't show it with current
> sources since psql is exiting on ^C, but 6.5 works like this:
> 
> play=> foobar
> play-> ^C
> CANCEL request sent
>                         <-- return typed here to get a prompt
> play-> select 2+2;
> ERROR:  parser: parse error at or near "foobar"
> play=>
> 
> Notice the prompt correctly shows that I still have stuff in the
> query buffer after ^C.  I think Chris is saying that ^C should
> flush the buffer like \r does ... and I agree.
> 
>                         regards, tom lane

Thu, 17 Feb 2000 15:44:07 +1100
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Re: [HACKERS] psql problem
On Wed, 16 Feb 2000, Tom Lane wrote:

> >> What?  Are you saying that control-C doesn't do a \r (reset the
> >> query buffer)?  That's probably true, and I agree that it should...
> 
> > Looks like it works fine:
> 
> > 	test=> select * from pg_class, pg_proc;
> > 	^C
> > 	Cancel request sent
> > 	ERROR:  Query was cancelled.
> > 	test=> 
> 
> No, I think Chris was complaining about the behavior with an
> incomplete query in the buffer.  I can't show it with current
> sources since psql is exiting on ^C, but 6.5 works like this:

Actually from reading Chris' note, he said that it was 'better than 
previous behaviour'.  Note the key word was *previous*.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
   128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Thu, 17 Feb 2000 05:56:54 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] psql problem 
On Thu, 17 Feb 2000, Chris Bitmead wrote:

> I was noticing that psql now exits on ctrl-C.

> But wouldn't it be better if it was like /bin/sh and
> popped you back to a fresh prompt or something?

I have, in fact, been muddling with this. If demand is there (apparently),
I can speed up the muddling.

For all of those that pretend to never have heard of this behaviour, I
explicitly announced it and even got several positive responses.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 17 Feb 2000 12:17:09 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] psql problem
On Wed, 16 Feb 2000, Tom Lane wrote:

> No, I think Chris was complaining about the behavior with an
> incomplete query in the buffer.  I can't show it with current
> sources since psql is exiting on ^C, but 6.5 works like this:
> 
> play=> foobar
> play-> ^C
> CANCEL request sent
>                         <-- return typed here to get a prompt

Actually, I have an idea why that is, too. The signal handler should tell
readline that input is done. At the time you press return there, it's
still reading input.

> play-> select 2+2;
> ERROR:  parser: parse error at or near "foobar"
> play=>

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 17 Feb 2000 12:21:03 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] psql problem 
On Wed, 16 Feb 2000, Bruce Momjian wrote:

> Peter E. can you look at this?  I see simple prompt doing:
> 
>         fputs(prompt, stdout);
> 
> which I think should be stderr.  Peter, can you check on those?

Will be fixed.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 17 Feb 2000 12:25:16 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] psql password prompt