Re: [HACKERS] psql \e broken again
>> I like Kevin Brown's suggestion of writing out a temporary .txt file and >> 'executing' it. It will follow the principle of least suprise for Windows >> users. > > Note that the current default behavior (assuming you've not set EDITOR) > is "vi foo.txt" which is quite unlikely to be helpful to a Windows user. works for me :-) but agreed not a good default. > I'm not sure we need to do the "execute a textfile" bit, but at the very I don't think that eighter. And also imho the obvious extension would be .sql, and that might not be registered, or already registered for another not really wanted sql tool. I think we need or own editor setting, the windows way would be a private registry setting, but using EDITOR is imho just as good. > least DEFAULT_EDITOR should probably be "notepad.exe" on Windows. Yes that would be a sane default on Windows. Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] psql \e broken again
"Bort, Paul" <[EMAIL PROTECTED]> writes: > I like Kevin Brown's suggestion of writing out a temporary .txt file and > 'executing' it. It will follow the principle of least suprise for Windows > users. Note that the current default behavior (assuming you've not set EDITOR) is "vi foo.txt" which is quite unlikely to be helpful to a Windows user. I'm not sure we need to do the "execute a textfile" bit, but at the very least DEFAULT_EDITOR should probably be "notepad.exe" on Windows. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] psql \e broken again
Title: RE: [HACKERS] psql \e broken again From: Zeugswetter Andreas DAZ SD [mailto:[EMAIL PROTECTED]] > > I am not sure the test is valid, since %EDITOR% was used on > the command line, > which does it's own magic on quotes. Is there a command that > would use the > envvar EDITOR without putting it on the commandline ? > > We are talking about directly using the envvar from inside > the program, no? > I wasn't sure either, but a quick trudge through my Windows-installed software that has been ported from *nix didn't show any programs that attempted to preserve that aspect of their behavior. CVSNT at least attempted to invoke an external editor, so I tested with that. I like Kevin Brown's suggestion of writing out a temporary .txt file and 'executing' it. It will follow the principle of least suprise for Windows users. And it is suprisingly easy to wait for a child process with the NT API. WaitForSingleObjectEx() ( http://tinyurl.com/5d4tj ) will wait with a timeout, so the caller can handle other messages or update counters as needed. ( We usually timeout every 1000ms and repeat the call until it returns a non-timeout status. )
Re: [HACKERS] psql \e broken again
>> So I thought I'd try a few scenarios, since I have it installed: >> [ none of which work ] >> So to answer your question, at least in part, there is no current good >> behavior to emulate. At least on this version of CVS: > I think this is fairly graphic proof that (1) a straight port without > doing anything special is essentially nonfunctional on Windows, and that > (2) there isn't any easy way for the user to fix it by inserting quotes > for himself. I am not sure the test is valid, since %EDITOR% was used on the command line, which does it's own magic on quotes. Is there a command that would use the envvar EDITOR without putting it on the commandline ? We are talking about directly using the envvar from inside the program, no? Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql \e broken again
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > >> Agreed, no quotes on Unix. I'm just wondering what to do > >> on Windows. > > > I don't think I've seen a single windows program that uses the EDITOR > > variable. There are some ported unix tools, but that's it. Native > > windows program will have a per-program setting for this. The system > > default is picked based on file extension. So I doubt it will break a > > lot of things. > > So are you in favor of not quoting at all --- ie, reverting to the Unix > behavior? I'm pretty sure that psql got changed because someone > complained, so it seems like we'd be going in circles if we just do that > and don't have any special behavior at all on Windows. You probably already know this but others on the list may not, so... The behavior of EDITOR under Unix comes about as a result of how it's invoked -- usually via the system() library call, which invokes a shell to parse the command. The fact that spaces in EDITOR's value are treated as argument delimeters instead of part of the path of the editor itself is a direct result of how the shell interprets the command string. It almost certainly doesn't make sense to retain those semantics under Windows, because to achieve real equivalence we would have to expand other shell metacharacters ourselves. Since Windows generally doesn't even make use of EDITOR as such, it probably makes the most sense for \e on that platform to save the edit buffer to a .txt file and "execute" it -- Windows will then invoke whichever editor is associated with text files (Notepad by default). It would have to be invoked in such a way that psql could wait for it to complete, of course. I suppose it might be nice to be able to override that, and do something else if EDITOR is defined. In that event it's probably safer to avoid parsing EDITOR and instead have it just refer to the full path to the program to be used. Someone who is savvy enough to define EDITOR is also savvy enough to throw together a simple batch file which invokes his real editor with whatever options he wants. It seems to me that being able to properly specify the path of the program to use with a minimum of fuss (hence no strange quoting conventions) takes precedence. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] psql \e broken again
"Bort, Paul" <[EMAIL PROTECTED]> writes: > The one that I see most often ( and use here ) is CVSGUI ( > http://www.wincvs.org/ ), which includes a CVS command-line client despite > the name. ( The command-line CVS might be from CVSNT, > http://www.cvsnt.com/cvspro/ ). > So I thought I'd try a few scenarios, since I have it installed: > [ none of which work ] > So to answer your question, at least in part, there is no current good > behavior to emulate. At least on this version of CVS: I think this is fairly graphic proof that (1) a straight port without doing anything special is essentially nonfunctional on Windows, and that (2) there isn't any easy way for the user to fix it by inserting quotes for himself. So it seems like we *must* double quote on Windows. If you want some switches in there, tough --- the only way will be to make a batch file you can invoke that adds the switches. Anyone see a different answer? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \e broken again
Title: RE: [HACKERS] psql \e broken again From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] > > Is there a Windows port of the command-line cvs tool? That > would be a > good thing to compare with. > The one that I see most often ( and use here ) is CVSGUI ( http://www.wincvs.org/ ), which includes a CVS command-line client despite the name. ( The command-line CVS might be from CVSNT, http://www.cvsnt.com/cvspro/ ). So I thought I'd try a few scenarios, since I have it installed: U:\sandbox\docbook> REM DOUBLE-QUOTES IN COMMAND LINE: U:\sandbox\docbook> set EDITOR=D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e "%EDITOR%" commit -D xml_reindent.pl 'D:\Program' is not recognized as an internal or external command, operable program or batch file. cvs commit: warning: editor session failed U:\sandbox\docbook> REM DOUBLE-QUOTES IN ENVIRONMENT VARIABLE: U:\sandbox\docbook> set EDITOR="D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe" U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e %EDITOR% commit -D xml_reindent.pl 'D:\Program' is not recognized as an internal or external command, operable program or batch file. cvs commit: warning: editor session failed U:\sandbox\docbook> REM DOUBLE-QUOTES IN BOTH: U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e "%EDITOR%" commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe' U:\sandbox\docbook> REM SINGLE-QUOTES IN ENVIRONMENT VARIABLE: U:\sandbox\docbook> set EDITOR='D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe' U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e %EDITOR% commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'' U:\sandbox\docbook> REM SINGLE-QUOTES IN COMMAND LINE: U:\sandbox\docbook> set EDITOR=D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e '%EDITOR%' commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'' U:\sandbox\docbook> REM SINGLE-QUOTES IN BOTH: U:\sandbox\docbook> set EDITOR='D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe' U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e '%EDITOR%' commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe''' U:\sandbox\docbook> REM BACKSLASH-ESCAPE SPACES: U:\sandbox\docbook> set EDITOR=D:\Program\ Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e %EDITOR% commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe' U:\sandbox\docbook> REM BACKSLASH-ESCAPE SPACES AND DOUBLE-QUOTE ON COMMAND LINE: U:\sandbox\docbook> set EDITOR=D:\Program\ Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e "%EDITOR%" commit -D xml_reindent.pl 'D:\Program\' is not recognized as an internal or external command, operable program or batch file. cvs commit: warning: editor session failed U:\sandbox\docbook> REM BACKSLASH-ESCAPE SPACES AND SINGLE-QUOTE ON COMMAND LINE: U:\sandbox\docbook> set EDITOR=D:\Program\ Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe U:\sandbox\docbook> cvs -d :sspi:[EMAIL PROTECTED]:/repo -e "%EDITOR%" commit -D xml_reindent.pl Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'' -- The message "is not recognized as an internal or external command..." is from the operating system, so CVS is at least trying to launch an editor in those cases. So to answer your question, at least in part, there is no current good behavior to emulate. At least on this version of CVS: Concurrent Versions System (CVSNT) 2.0.51d (client/server) Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVSNT version (Aug 19 2004) Copyright (c) 1999-2004 Tony Hoyle and others see http://www.cvsnt.org If you have any other combinations that might make sense, let me know, and I'll give it a try.
Re: [HACKERS] psql \e broken again
Peter Eisentraut wrote: Magnus Hagander wrote: I don't think I've seen a single windows program that uses the EDITOR variable. There are some ported unix tools, but that's it. Native windows program will have a per-program setting for this. The system default is picked based on file extension. So I doubt it will break a lot of things. Is there a Windows port of the command-line cvs tool? That would be a good thing to compare with. CVSNT (internally used by wincvs), website at www.cvsnt.org/wiki Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql \e broken again
Magnus Hagander wrote: > I don't think I've seen a single windows program that uses the EDITOR > variable. There are some ported unix tools, but that's it. Native > windows program will have a per-program setting for this. The system > default is picked based on file extension. So I doubt it will break a > lot of things. Is there a Windows port of the command-line cvs tool? That would be a good thing to compare with. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql \e broken again
> > We could maybe compromise with (again, for Windows only) a > policy like > > "double-quote unless the value already contains at least one > > double-quote". This should work conveniently for everybody > except the > > user who wants EDITOR='gvim.exe -y' on Windows; he'll have > to add some > > useless-looking double quotes a la EDITOR='"gvim.exe" -y'. > > Single quotes don't work on Windows (tried with %EDITOR% > x.txt). I think we should not worry too much since the user > could use the "good old" > EDITOR=C:/PROGRA~1/vim/vim63/gvim.exe -y syntax on win if all > else fails. No we can't assume people can do that :-) Anybody who's running at least a server for max file performance (or when you're talking a web server in some cases certainly for security as well) run with 8.3 filenames turned off per http://support.microsoft.com/kb/121007. It's not uncommon to see this pushed out with Group Policy as well. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql \e broken again
> >> Agreed, no quotes on Unix. I'm just wondering what to do > on Windows. > > > I don't think I've seen a single windows program that uses > the EDITOR > > variable. There are some ported unix tools, but that's it. Native > > windows program will have a per-program setting for this. > The system > > default is picked based on file extension. So I doubt it > will break a > > lot of things. > > So are you in favor of not quoting at all --- ie, reverting > to the Unix behavior? I'm pretty sure that psql got changed > because someone complained, so it seems like we'd be going in > circles if we just do that and don't have any special > behavior at all on Windows. Not really sure. In my case it would be acceptable to have it require me to put the quotes in the environment variable, since I've never seen any other programs use it. It just needs to be clearly documented somehow (and didn't it cause a psql *crash* before? That's certainly not acceptable, it has to kick out an error msg). Should probably be checked with the guy who had the original complaint, though. The second choice solution would probably be to do the quoting but only on windows. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql \e broken again
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Agreed, no quotes on Unix. I'm just wondering what to do >> on Windows. > I don't think I've seen a single windows program that uses the EDITOR > variable. There are some ported unix tools, but that's it. Native > windows program will have a per-program setting for this. The system > default is picked based on file extension. So I doubt it will break a > lot of things. So are you in favor of not quoting at all --- ie, reverting to the Unix behavior? I'm pretty sure that psql got changed because someone complained, so it seems like we'd be going in circles if we just do that and don't have any special behavior at all on Windows. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] psql \e broken again
> >> Agreed, no quotes on Unix. I'm just wondering what to do > on Windows. > > > I would require the user to add quotes around his > executable if it has > > spaces. > > > set EDITOR="C:/Program Files/vim/vim63/gvim.exe" -y > > I think this policy is OK for the Mac OS X case, but I am > wondering if it will cause any compatibility problems on > Windows. In particular, if other programs expect to > double-quote EDITOR themselves, then there'd be no way to > make the same value work for both PG and the others. I don't think I've seen a single windows program that uses the EDITOR variable. There are some ported unix tools, but that's it. Native windows program will have a per-program setting for this. The system default is picked based on file extension. So I doubt it will break a lot of things. If we're very worried about this, how about using PGEDITOR instead of EDITOR? //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql \e broken again
> We could maybe compromise with (again, for Windows only) a policy like > "double-quote unless the value already contains at least one > double-quote". This should work conveniently for everybody except the > user who wants EDITOR='gvim.exe -y' on Windows; he'll have to add > some useless-looking double quotes a la EDITOR='"gvim.exe" -y'. Single quotes don't work on Windows (tried with %EDITOR% x.txt). I think we should not worry too much since the user could use the "good old" EDITOR=C:/PROGRA~1/vim/vim63/gvim.exe -y syntax on win if all else fails. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql \e broken again
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes: >> Agreed, no quotes on Unix. I'm just wondering what to do on Windows. > I would require the user to add quotes around his executable if it has > spaces. > set EDITOR="C:/Program Files/vim/vim63/gvim.exe" -y I think this policy is OK for the Mac OS X case, but I am wondering if it will cause any compatibility problems on Windows. In particular, if other programs expect to double-quote EDITOR themselves, then there'd be no way to make the same value work for both PG and the others. So it seems like we need to look and see if there's precedent for the handling of EDITOR in Unix programs transplanted to Windows. We could maybe compromise with (again, for Windows only) a policy like "double-quote unless the value already contains at least one double-quote". This should work conveniently for everybody except the user who wants EDITOR='gvim.exe -y' on Windows; he'll have to add some useless-looking double quotes a la EDITOR='"gvim.exe" -y'. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \e broken again
On Sun, Nov 14, 2004 at 10:14:06PM -0500, Bruce Momjian wrote: John Hansen wrote: 1. Quote only on Windows. 2. Expect user to put quotes in the EDITOR value if it contains a space-containing path. As far I I'm aware, the options on windows are very much like those on unix: "path containing spaces" or path\ containing\ spaces My guess is that we should only address spaces on Win32, but should document why did didn't do it on Unix. Also, what about OS X? Doesn't that have frequent spaces in file paths? The underside of MacOS X is BSD-flavor Unix of course. For anyone setting an environment variables, they are playing directly with that layer. I'd recommend leaving it as you do for all Unix varieties and a user can can quote or backslash-escape, just as he or she can on any other Unix. As precedent, other utilities, like 'find' don't to anything special with the spaces, which can cause complications if you don't know to anticipate dealing with that. -Travis ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql \e broken again
>> The EDITOR variable seems to have a fairly standard meaning on Unix >> systems. I've been using that EDITOR value for years without problems, >> only when I use psql's \e once in a while it breaks. I don't think we >> should deviate from what seems to be a standard practice. > > Agreed, no quotes on Unix. I'm just wondering what to do on Windows. I would require the user to add quotes around his executable if it has spaces. set EDITOR="C:/Program Files/vim/vim63/gvim.exe" -y Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \e broken again
hi, As for mac os x this is on darwin mac os (it's mac something) I ran a find command with a space in it. mechatronics:~ joe$ find . -name '* *' ./backups/dscpadmin/scriptsMay19/dscp/validate/List of Cancers.doc ./backups/pain/PAINjune/validate/List of Cancers.doc ./backups/untarhere/test/List of Cancers.doc ./Library/Address Book Plug-Ins ./Library/Application Support ./Library/Caches/Desktop/Desktop Pictures.dpImageCache ./Library/Caches/Desktop/Solid Colors.dpImageCache ./Library/Caches/iPhoto Cache ./Library/Caches/Software Update ./Library/FontCollections/Fixed Width.collection ./Library/iMovie/Sound Effects ./Library/Internet Plug-Ins ./Library/Keyboard Layouts ./Library/Preferences/QuickTime Preferences ./Library/Safari/Form Values ./Public/Drop Box On Sun, Nov 14, 2004 at 10:14:06PM -0500, Bruce Momjian wrote: > John Hansen wrote: > > > > 1. Quote only on Windows. > > > > > > > > 2. Expect user to put quotes in the EDITOR value if it contains a > > > > space-containing path. > > > > > > As far I I'm aware, the options on windows are very much like those on > > unix: > > > > "path containing spaces" or > > path\ containing\ spaces > > My guess is that we should only address spaces on Win32, but should > document why did didn't do it on Unix. Also, what about OS X? Doesn't > that have frequent spaces in file paths? > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html -- if you're christian, god bless; otherwise, good luck; and, if you dont believe in luck ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] psql \e broken again
John Hansen wrote: > > > 1. Quote only on Windows. > > > > > > 2. Expect user to put quotes in the EDITOR value if it contains a > > > space-containing path. > > > As far I I'm aware, the options on windows are very much like those on > unix: > > "path containing spaces" or > path\ containing\ spaces My guess is that we should only address spaces on Win32, but should document why did didn't do it on Unix. Also, what about OS X? Doesn't that have frequent spaces in file paths? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql \e broken again
> > 1. Quote only on Windows. > > > > 2. Expect user to put quotes in the EDITOR value if it contains a > > space-containing path. As far I I'm aware, the options on windows are very much like those on unix: "path containing spaces" or path\ containing\ spaces Kind Regards John Hansen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \e broken again
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The EDITOR variable seems to have a fairly standard meaning on Unix > systems. I've been using that EDITOR value for years without problems, > only when I use psql's \e once in a while it breaks. I don't think we > should deviate from what seems to be a standard practice. Agreed, no quotes on Unix. I'm just wondering what to do on Windows. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql \e broken again
Tom Lane wrote: > I think the rationale was to allow paths containing spaces, which is > a pretty serious problem on Windows. Seems like we have two basic > options: > > 1. Quote only on Windows. > > 2. Expect user to put quotes in the EDITOR value if it contains a > space-containing path. The EDITOR variable seems to have a fairly standard meaning on Unix systems. I've been using that EDITOR value for years without problems, only when I use psql's \e once in a while it breaks. I don't think we should deviate from what seems to be a standard practice. I wonder whether a similar convention exists on Windows. I could certainly live with quoting only on Windows if that is what the convention is there. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql \e broken again
Peter Eisentraut <[EMAIL PROTECTED]> writes: > A remember specifically that I somewhat recently fixed psql to accept > editors with arguments, say EDITOR="pico -t". This was apparently > broken again during some Windows-related reshuffling. It now takes the > editor as one quoted string rather than possibly several shell tokens. > Could this please be fixed? I think the rationale was to allow paths containing spaces, which is a pretty serious problem on Windows. Seems like we have two basic options: 1. Quote only on Windows. 2. Expect user to put quotes in the EDITOR value if it contains a space-containing path. I don't much care for either of these :-(. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] psql \e broken again
A remember specifically that I somewhat recently fixed psql to accept editors with arguments, say EDITOR="pico -t". This was apparently broken again during some Windows-related reshuffling. It now takes the editor as one quoted string rather than possibly several shell tokens. Could this please be fixed? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match