Thread: 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/
Peter Eisentraut <peter_e@gmx.net> 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
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/
Peter Eisentraut <peter_e@gmx.net> 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
> > 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
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 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
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 > 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, 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 ...
>> 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
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
"Zeugswetter Andreas DAZ SD" <ZeugswetterA@spardat.at> 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
> 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
> >> 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
> > 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
"Magnus Hagander" <mha@sollentuna.net> 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
> >> 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
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/
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
<p><font size="2">From: Peter Eisentraut [<a href="mailto:peter_e@gmx.net">mailto:peter_e@gmx.net</a>]</font><br /><fontsize="2">> </font><br /><font size="2">> Is there a Windows port of the command-line cvs tool? That </font><br/><font size="2">> would be a </font><br /><font size="2">> good thing to compare with.</font><br /><fontsize="2">> </font><p><font size="2">The one that I see most often ( and use here ) is CVSGUI ( <a href="http://www.wincvs.org/"target="_blank">http://www.wincvs.org/</a> ), which includes a CVS command-line client despitethe name. ( The command-line CVS might be from CVSNT, <a href="http://www.cvsnt.com/cvspro/" target="_blank">http://www.cvsnt.com/cvspro/</a>).</font><p><font size="2">So I thought I'd try a few scenarios, since Ihave it installed:</font><p><font size="2">U:\sandbox\docbook> REM DOUBLE-QUOTES IN COMMAND LINE:</font><br /><font size="2">U:\sandbox\docbook>set EDITOR=D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe</font><br /><fontsize="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo -e "%EDITOR%" commit -D xml_reindent.pl</font><br/><font size="2">'D:\Program' is not recognized as an internal or external command,</font><br /><fontsize="2">operable program or batch file.</font><br /><font size="2">cvs commit: warning: editor session failed</font><p><fontsize="2">U:\sandbox\docbook> REM DOUBLE-QUOTES IN ENVIRONMENT VARIABLE:</font><br /><font size="2">U:\sandbox\docbook>set EDITOR="D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe"</font><br /><fontsize="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo -e %EDITOR% commit -D xml_reindent.pl</font><br/><font size="2">'D:\Program' is not recognized as an internal or external command,</font><br /><fontsize="2">operable program or batch file.</font><br /><font size="2">cvs commit: warning: editor session failed</font><p><fontsize="2">U:\sandbox\docbook> REM DOUBLE-QUOTES IN BOTH:</font><br /><font size="2">U:\sandbox\docbook>cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo -e "%EDITOR%" commit -D xml_reindent.pl</font><br/><font size="2">Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'</font><p><fontsize="2">U:\sandbox\docbook> REM SINGLE-QUOTES INENVIRONMENT VARIABLE:</font><br /><font size="2">U:\sandbox\docbook> set EDITOR='D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'</font><br/><font size="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo-e %EDITOR% commit -D xml_reindent.pl</font><br /><font size="2">Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe''</font><p><fontsize="2">U:\sandbox\docbook> REM SINGLE-QUOTES INCOMMAND LINE:</font><br /><font size="2">U:\sandbox\docbook> set EDITOR=D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe</font><br/><font size="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo-e '%EDITOR%' commit -D xml_reindent.pl</font><br /><font size="2">Unknown command:`Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe''</font><p><font size="2">U:\sandbox\docbook> REM SINGLE-QUOTESIN BOTH:</font><br /><font size="2">U:\sandbox\docbook> set EDITOR='D:\Program Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'</font><br/><font size="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo-e '%EDITOR%' commit -D xml_reindent.pl</font><br /><font size="2">Unknown command:`Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'''</font><p><font size="2">U:\sandbox\docbook> REM BACKSLASH-ESCAPESPACES:</font><br /><font size="2">U:\sandbox\docbook> set EDITOR=D:\Program\ Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe</font><br/><font size="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo-e %EDITOR% commit -D xml_reindent.pl</font><br /><font size="2">Unknown command: `Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe'</font><p><fontsize="2">U:\sandbox\docbook> REM BACKSLASH-ESCAPESPACES AND DOUBLE-QUOTE ON COMMAND LINE:</font><br /><font size="2">U:\sandbox\docbook> set EDITOR=D:\Program\Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe</font><br /><font size="2">U:\sandbox\docbook>cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo -e "%EDITOR%" commit -D xml_reindent.pl</font><br/><font size="2">'D:\Program\' is not recognized as an internal or external command,</font><br /><fontsize="2">operable program or batch file.</font><br /><font size="2">cvs commit: warning: editor session failed</font><p><fontsize="2">U:\sandbox\docbook> REM BACKSLASH-ESCAPE SPACES AND SINGLE-QUOTE ON COMMAND LINE:</font><br/><font size="2">U:\sandbox\docbook> set EDITOR=D:\Program\ Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe</font><br/><font size="2">U:\sandbox\docbook> cvs -d :sspi:pbort@cleqa.tmwsystems.com:/repo-e "%EDITOR%" commit -D xml_reindent.pl</font><br /><font size="2">Unknown command:`Files\XEmacs\XEmacs-21.4.13\i586-pc-win32\XEmacs.exe''</font><p><font size="2">------</font><p><font size="2">Themessage "is not recognized as an internal or external command..." is from the operating system, so CVS is atleast trying to launch an editor in those cases.</font><p><font size="2">So to answer your question, at least in part,there is no current good behavior to emulate. At least on this version of CVS:</font><p><font size="2">Concurrent VersionsSystem (CVSNT) 2.0.51d (client/server)</font><p><font size="2">Copyright (c) 1989-2001 Brian Berliner, david d `zoo'zuhn,</font><br /><font size="2"> Jeff Polk, and other authors</font><br /><font size="2">CVSNTversion (Aug 19 2004) Copyright (c) 1999-2004 Tony Hoyle and others</font><br /><font size="2">see <a href="http://www.cvsnt.org"target="_blank">http://www.cvsnt.org</a></font><p><font size="2">If you have any other combinationsthat might make sense, let me know, and I'll give it a try.</font>
"Bort, Paul" <pbort@tmwsystems.com> 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
Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> 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 kevin@sysexperts.com
>> 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
<br /><p><font size="2">From: Zeugswetter Andreas DAZ SD [<a href="mailto:ZeugswetterA@spardat.at">mailto:ZeugswetterA@spardat.at</a>]</font><br/><font size="2">> </font><br /><fontsize="2">> I am not sure the test is valid, since %EDITOR% was used on </font><br /><font size="2">> the commandline,</font><br /><font size="2">> which does it's own magic on quotes. Is there a command that </font><br /><fontsize="2">> would use the </font><br /><font size="2">> envvar EDITOR without putting it on the commandline ?</font><br/><font size="2">> </font><br /><font size="2">> We are talking about directly using the envvar from inside</font><br /><font size="2">> the program, no?</font><br /><font size="2">> </font><p><font size="2">I wasn'tsure either, but a quick trudge through my Windows-installed software that has been ported from *nix didn't show anyprograms that attempted to preserve that aspect of their behavior. CVSNT at least attempted to invoke an external editor,so I tested with that. </font><p><font size="2">I like Kevin Brown's suggestion of writing out a temporary .txt fileand 'executing' it. It will follow the principle of least suprise for Windows users. And it is suprisingly easy to waitfor a child process with the NT API. WaitForSingleObjectEx() ( <a href="http://tinyurl.com/5d4tj" target="_blank">http://tinyurl.com/5d4tj</a>) will wait with a timeout, so the caller can handle other messages or updatecounters as needed. ( We usually timeout every 1000ms and repeat the call until it returns a non-timeout status. )</font>
"Bort, Paul" <pbort@tmwsystems.com> 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
>> 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