Обсуждение: Request for a "force interactive mode" flag (-I) for psql
Back in 2003 Bruce Momjian proposed adding a flag (-I) to psql to force it into "interactive" mode. (See http://archives.postgresql.org/pgsql-hackers/2003-11/msg00013.php for the thread.) The proposal was rejected because there was no proven need for it at that time. I'd like to raise this proposal again, since I think in our situation, this is the only fix for our problem. Our environment is as follows: * A large number of PostgreSQL 7.4 servers running on a variety of SuSE Linux (9.0 - 9.3) servers * A growing number of PostgreSQL 8.0.3 servers running on Windows Server 2003 servers. (We are running the native Win32 version of PostgreSQL, not the Cygwin version.) The servers are all located in remote offices. Maintenance is done remotely via SSH to a "local" bash command prompt where we use the command line tools: psql, pg_dump, etc. On Linux we use the native sshd; on Windows we use Cygwin to get bash, sshd, cron, etc. On Linux this works fine; on Windows, however, psql thinks it is not in an interactive console so we get no prompts, no line editing, no history, very little cursor control, etc. (I see that the missing autocomplete feature is a readline issue, but that's a topic for another posting.) This makes remote maintenance on the Windows servers much more difficult than it otherwise could be. The issue appears to be due to isatty() returning false in the Windows Cygwin environment. From other research around the web, it appears that if the app is "Cygwin-aware" is knows to override this check (or allow manual override) or try to do further testing, but in this case, since we are using the native Win32 version of PostgreSQL, psql doesn't do any additional testing. Also, even in the local console on Windows, running rxvt -- our preferred terminal in Windows (since it lets us make our Windows command line act just like our Linux command line <grin>) -- causes psql to think that there is no terminal. (Our first encounter of this "no terminal" problem was in trying to run psql via a local bash shell via rxvt, and originally we thought that psql was hanging. Given our reliance on psql for remote maintenance, this would have prevented our rolling out a Windows version of PostgreSQL. It was only after too much time looking at it with some low-level tools that we stumbled across the fact that psql was simply silently waiting at a command prompt rather than being hung. However, from other posts in these lists [e.g.: http://archives.postgresql.org/pgsql-patches/2004-07/msg00369.php ] it appears that other people also thought psql was hanging when it was run from a terminal program, so I suppose I shouldn't feel too bad...) Bruce's proposal and suggested code simply added a new "-I" flag to force psql into "interactive mode" (by simply setting "pset.notty = 0"). From everything I can find (including reading through the Cygwin code, ssh and sshd man pages and code, psql code, testing various modes of running the sshd service in Windows, changing Windows profile account permissions, etc.), adding this flag seems to be the only viable option (other than writing a replacement for psql for our Windows servers, something I'd prefer to not do). While I can obviously add this patch myself and build and maintain a custom version of psql for our own use, since there now is a true native version of PostgreSQL for Windows, I think we will see a growing list of people supporting mixed environments just like ours, and bumping into this exact same problem. Thoughts? - Bill Bill Bartlett meridianEMR, Inc. http://www.meridianemr.com
I haven't seen any replies to this, so I guess you are left with either hacking psql yourself or getting Cygwin folks to fix it. Sorry. --------------------------------------------------------------------------- Bill Bartlett wrote: > Back in 2003 Bruce Momjian proposed adding a flag (-I) to psql to force > it into "interactive" mode. (See > http://archives.postgresql.org/pgsql-hackers/2003-11/msg00013.php for > the thread.) The proposal was rejected because there was no proven need > for it at that time. I'd like to raise this proposal again, since I > think in our situation, this is the only fix for our problem. > > Our environment is as follows: > * A large number of PostgreSQL 7.4 servers running on a variety of SuSE > Linux (9.0 - 9.3) servers > * A growing number of PostgreSQL 8.0.3 servers running on Windows Server > 2003 servers. (We are running the native Win32 version of PostgreSQL, > not the Cygwin version.) > > The servers are all located in remote offices. Maintenance is done > remotely via SSH to a "local" bash command prompt where we use the > command line tools: psql, pg_dump, etc. On Linux we use the native > sshd; on Windows we use Cygwin to get bash, sshd, cron, etc. On Linux > this works fine; on Windows, however, psql thinks it is not in an > interactive console so we get no prompts, no line editing, no history, > very little cursor control, etc. (I see that the missing autocomplete > feature is a readline issue, but that's a topic for another posting.) > This makes remote maintenance on the Windows servers much more difficult > than it otherwise could be. > > The issue appears to be due to isatty() returning false in the Windows > Cygwin environment. From other research around the web, it appears that > if the app is "Cygwin-aware" is knows to override this check (or allow > manual override) or try to do further testing, but in this case, since > we are using the native Win32 version of PostgreSQL, psql doesn't do any > additional testing. > > Also, even in the local console on Windows, running rxvt -- our > preferred terminal in Windows (since it lets us make our Windows command > line act just like our Linux command line <grin>) -- causes psql to > think that there is no terminal. (Our first encounter of this "no > terminal" problem was in trying to run psql via a local bash shell via > rxvt, and originally we thought that psql was hanging. Given our > reliance on psql for remote maintenance, this would have prevented our > rolling out a Windows version of PostgreSQL. It was only after too much > time looking at it with some low-level tools that we stumbled across the > fact that psql was simply silently waiting at a command prompt rather > than being hung. However, from other posts in these lists [e.g.: > http://archives.postgresql.org/pgsql-patches/2004-07/msg00369.php ] it > appears that other people also thought psql was hanging when it was run > from a terminal program, so I suppose I shouldn't feel too bad...) > > Bruce's proposal and suggested code simply added a new "-I" flag to > force psql into "interactive mode" (by simply setting "pset.notty = 0"). > >From everything I can find (including reading through the Cygwin code, > ssh and sshd man pages and code, psql code, testing various modes of > running the sshd service in Windows, changing Windows profile account > permissions, etc.), adding this flag seems to be the only viable option > (other than writing a replacement for psql for our Windows servers, > something I'd prefer to not do). While I can obviously add this patch > myself and build and maintain a custom version of psql for our own use, > since there now is a true native version of PostgreSQL for Windows, I > think we will see a growing list of people supporting mixed environments > just like ours, and bumping into this exact same problem. > > Thoughts? > > - Bill > > Bill Bartlett > meridianEMR, Inc. > http://www.meridianemr.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Oct 13, 2005, at 4:42 PM, Bruce Momjian wrote: > I haven't seen any replies to this, so I guess you are left with > either > hacking psql yourself or getting Cygwin folks to fix it. Sorry. I have asked for this also. It would make it much easier to control psql from other applications. http://archives.postgresql.org/pgsql-hackers/2005-04/threads.php It seems pretty simple and non-invasive. I don't recall seeing the reasons against doing it. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
John DeSoi wrote: > > On Oct 13, 2005, at 4:42 PM, Bruce Momjian wrote: > > > I haven't seen any replies to this, so I guess you are left with > > either > > hacking psql yourself or getting Cygwin folks to fix it. Sorry. > > I have asked for this also. It would make it much easier to control > psql from other applications. > > http://archives.postgresql.org/pgsql-hackers/2005-04/threads.php > > It seems pretty simple and non-invasive. I don't recall seeing the > reasons against doing it. We need a large number of users who need something before we add it. If we didn't we would have a mess of options. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
>>http://archives.postgresql.org/pgsql-hackers/2005-04/threads.php >> >>It seems pretty simple and non-invasive. I don't recall seeing the >>reasons against doing it. >> >> > >We need a large number of users who need something before we add it. If >we didn't we would have a mess of options. > > The need seems like the exception rather than the norm. The posts that I see are people trying to use Unix tools, in Windows. I am not talking about the use of psql, rather things like the use of Cygwin and rxvt. Although it is nice when we can do that, it should be consider unsupported. If you really want the environment, use RDP, VNC, or Citrix and start a shell as normal. Alternatively just use PostgreSQL with SSL and then connect from a remote psql terminal. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
What I couldn't work out was why the original requester didn't use the Cygwin psql client, which should work just fine, instead of trying to use the native client which we know has serious limitations. cheers andrew Joshua D. Drake said: > >>>http://archives.postgresql.org/pgsql-hackers/2005-04/threads.php >>> >>>It seems pretty simple and non-invasive. I don't recall seeing the >>>reasons against doing it. >>> >>> >> >>We need a large number of users who need something before we add it. >>If we didn't we would have a mess of options. >> >> > The need seems like the exception rather than the norm. The posts that > I see are people > trying to use Unix tools, in Windows. I am not talking about the use of > psql, rather things > like the use of Cygwin and rxvt. Although it is nice when we can do > that, it should > be consider unsupported. > > If you really want the environment, use RDP, VNC, or Citrix and start a > shell as normal. > Alternatively just use PostgreSQL with SSL and then connect from a > remote psql terminal. > > Sincerely, > > Joshua D. Drake > > > > > > -- > Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 > PostgreSQL Replication, Consulting, Custom Programming, 24x7 support > Managed Services, Shared and Dedicated Hosting > Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ > > > ---------------------------(end of > broadcast)--------------------------- TIP 9: In versions below 8.0, the > planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match