Thread: psql password prompt
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,
Pennsylvania19026
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?
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
> > 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, Pennsylvania19026
> 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;^CCancel request sentERROR: 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, Pennsylvania19026
>> 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
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
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/moor less at Pop4 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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
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
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