psql \e broken again
Peter Eisentraut
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
Tom Lane
> 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
Peter Eisentraut
> 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.
Tom Lane
> 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 majo...@postgresql.org so that your
message can get through to the mailing list cleanly
John Hansen
> >
> > 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
Bruce Momjian
> > > 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
pg...@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?
joseph speigle
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
--
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 majo...@postgresql.org)
Zeugswetter Andreas DAZ SD
>> 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
Travis P
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
Tom Lane
>> 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
Zeugswetter Andreas DAZ SD
> 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?
Magnus Hagander
> 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
Magnus Hagander
> 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)---------------------------
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
Magnus Hagander
> 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)---------------------------
Peter Eisentraut
> 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/
Andreas Pflug
> 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
Bort, Paul
From: Peter Eisentraut [mailto:pet...@gmx.net]
>
> 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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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:pb...@cleqa.tmwsystems.com:/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.
Tom Lane
> 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)---------------------------
Kevin Brown
> "Magnus Hagander" <m...@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 ke...@sysexperts.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Zeugswetter Andreas DAZ SD
>> 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 majo...@postgresql.org
Bort, Paul
From: Zeugswetter Andreas DAZ SD [mailto:Zeugsw...@spardat.at]
>
> 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. )
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.
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)---------------------------
Zeugswetter Andreas DAZ SD
>> '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