psql \e broken again

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, Pennsylvania 19073

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

From: Peter Eisentraut [mailto:peter_e@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:pbort@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:pbort@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:pbort@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:pbort@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:pbort@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:pbort@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:pbort@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:pbort@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:pbort@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.

"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

From: Zeugswetter Andreas DAZ SD [mailto:ZeugswetterA@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. )

"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

I have made similar adjustments to SHELL like we did with EDITOR ---
patch attached. I quote only for Win32.

---------------------------------------------------------------------------

Peter Eisentraut wrote:

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

-- 
  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