psql & readline & win32
Getting started early this year, I've finally found a way around the issues with readline on win32. And it just took a little bit of google research and some testing.
Recap of the problem: When running psql in a readline enabled mode on win32, any character requiring the AltGr key to generate will not work. In a lot of non-US locales, this includes the backslash key, which makes psql pretty darn unusable. The "fix" for this that went into 8.0 is to disable readline on win32 pending a fix.
Now, this can be fixed. And it's as simple as specifying an inputrc file. For backslash, this file needs to contain:
"\M-\\": "\\"
And then similarly for every other character requiring AltGr.
Considering we have a fix, I think we need to re-enable readline on win32, and document this. However, there are a couple of things to decide on first:
1) Should it be made default? As it requires you to include this file to work, perhaps it should be set to non-default and specifically require a --with-readline? Also depends on th eanswers of a couple of questions below, I think.
2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include "\@£${[]}~|"). Which would help people a lot.
3) How should the inputrc file be loaded. By default, you have to type SET INPUTRC="\some\where\inputrc" before you launch psql. But we could just as easily add:
#if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc);
#endif
to psql, making that step a whole lot easier. Especially for people who launch psql from the startmenu, and can't specify program-specific env vars.
If we wanted to, we could even bind the keys using rl_parse_and_bind() or similar, but keeping it in a separate file makes it possible to edit it without recompiling, which is a definite plus.
4) Can we ship linked with readline in the installer? If not, can we ship a readline-linked binary at all, or just the source? Considering readline drags along the GPL, and not just the LGPL. (We can link either statically (default) or dynamically (separate package) to readline without problems, from what I can tell)
I think we ship readline-linked RPMs, but I'm not sure about that?
Now even if we can't ship readline linked binaries in the installer, it's still a good thing to provide the ability to build them, of course :-)
//Magnus
Magnus Hagander wrote:
Considering we have a fix, I think we need to re-enable readline on win32, and document this. However, there are a couple of things to decide on first:
1) Should it be made default? As it requires you to include this file to work, perhaps it should be set to non-default and specifically require a --with-readline? Also depends on th eanswers of a couple of questions below, I think.
Good work.
It should be the default - if we find readline we should use it. I guess
that means the installer would need to ship the readline DLL, along with
all the other third party DLLs it ships.
2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include "\@�${[]}~|"). Which would help people a lot.
Yes we should, at least for Windows - put it in share along with other
samples, maybe.
3) How should the inputrc file be loaded. By default, you have to type SET INPUTRC="\some\where\inputrc" before you launch psql. But we could just as easily add:
#if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc);
#endif
to psql, making that step a whole lot easier. Especially for people who launch psql from the startmenu, and can't specify program-specific env vars.
if user has $HOME/inputrc
load $HOME/inputrc
elsif exists $SYSTEMCONFIG/inputrc
load $SYSTEMCONFIG/inputrc
endif
Since inputrc is meant to service many applications, we shouldn't try to
bypass that.
cheers
andrew
4) Can we ship linked with readline in the installer? If not, can we ship a readline-linked binary at all, or just the source? Considering readline drags along the GPL, and not just the LGPL. (We can link either statically (default) or dynamically (separate package) to readline without problems, from what I can tell)
This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)
cheers
andrew
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
Magnus Hagander wrote:
4) Can we ship linked with readline in the installer? If not, can we ship
a readline-linked binary at all, or just the source? Considering readline
drags along the GPL, and not just the LGPL. (We can link either
statically (default) or dynamically (separate package) to readline
without problems, from what I can tell)This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)
I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed. If
I were trying to use the windows installer in a commercial application, I
sure wouldn't want that liability.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)
I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed.
Robert is 100% right. If the Readline people wanted non-GPL packages
linking to their code, they'd have used LGPL not GPL. We must not
ignore their clear intentions; to do so is certainly unethical and
probably illegal.
Anyone for trying to port BSD libedit to work on Windows?
(Of course, you could also treat the Windows installer as being entirely
GPL-licensed, which would effectively comply with both upstream
licenses. But I don't find that an appealing solution.)
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> wrote
Anyone for trying to port BSD libedit to work on Windows?
Maybe just let it be on Windows is acceptable. I am currently happy with my
psql without readline support on Windows, but on Unix that's hard. If
Windows users want more advanced client, there are a bunch of GUI tools.
Regards,
Qingqing
Robert Treat <xzilla@users.sourceforge.net> writes:
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
This has been debated ad nauseam in the past. The consensus, bar a
few people with more advanced paranoia than I suffer from,is that we
can ;-)
I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that yourpackage is bsd licensed.
Robert is 100% right. If the Readline people wanted non-GPL
packages linking to their code, they'd have used LGPL not
GPL. We must not ignore their clear intentions; to do so is
certainly unethical and probably illegal.
Does it make a difference if we ship it dynamically linked against a
DLL? Because we can do that pretty easily.
Anyone for trying to port BSD libedit to work on Windows?
I googled a bit on that as well, and turns out that somebody did try it,
and it wasn't easy. And from what I can tell, not complete yet.
http://www.coldie.net/node/131
I'm sure it *can* be done, but it's probably quite a bit of work.
(Of course, you could also treat the Windows installer as
being entirely GPL-licensed, which would effectively comply
with both upstream licenses. But I don't find that an
appealing solution.)
Me either.
Though we do ship GPL stuff in it already - postgis to be specific. But
we don't link against that, we just load the module at runtime...
//Magnus
Import Notes
Resolved by subject fallback
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Andrew Dunstan
Sent: Sun 1/1/2006 11:51 PM
To: Magnus Hagander
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql & readline & win32
4) Can we ship linked with readline in the installer?
If not, can we ship a readline-linked binary at all,
or just the source? Considering readline drags along
the GPL, and not just the LGPL. (We can link either
statically (default) or dynamically (separate package)
to readline without problems, from what I can tell)
This has been debated ad nauseam in the past. The consensus,
bar a few people with more advanced paranoia than I suffer
from, is that we can ;-)
The installer is a little different though, in that we would have to actually ship readline as part of the distro, as it's unlikely to be pre-installed on the OS. At best we would have to start shipping it's source as well, at worst it would make everything else in the package that uses it GPL as well.
IANAL of course, but my self preservation instincts tell me to err on the side of caution.
Regards, Dave
Import Notes
Resolved by subject fallback
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Tom Lane
Sent: Mon 1/2/2006 3:30 AM
To: Robert Treat
Cc: pgsql-hackers@postgresql.org; Andrew Dunstan; Magnus Hagander
Subject: Re: [HACKERS] psql & readline & win32
(Of course, you could also treat the Windows installer as being entirely
GPL-licensed, which would effectively comply with both upstream
licenses. But I don't find that an appealing solution.)
Ain't gonna happen whilst pgAdmin is in there. The words 'over' and 'dead decaying corpse' spring to mind :-p
Not to mention that we can't just change the licence anyway...
/D
Import Notes
Resolved by subject fallback
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Magnus Hagander
Sent: Mon 1/2/2006 8:08 AM
To: Tom Lane; Robert Treat
Cc: pgsql-hackers@postgresql.org; Andrew Dunstan
Subject: Re: [HACKERS] psql & readline & win32
Though we do ship GPL stuff in it already - postgis to
be specific. But we don't link against that, we just
load the module at runtime...
And of course, they *want* us to ship their code. The GNU folks most likely couldn't care less meaning they're far more likely to get annoyed if we unintentionally misinterpret the licence.
Regards, Dave
Import Notes
Resolved by subject fallback
Robert Treat said:
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
Magnus Hagander wrote:
4) Can we ship linked with readline in the installer? If not, can we
ship
a readline-linked binary at all, or just the source? Considering
readline drags along the GPL, and not just the LGPL. (We can link
either statically (default) or dynamically (separate package) to
readline without problems, from what I can tell)This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can
;-)I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that your package is
bsd licensed. If I were trying to use the windows installer in a
commercial application, I sure wouldn't want that liability.
Why should we statically link it?
How well maintained is libedit? I'd feel happier about a switch if I could
find a maintained home page for it.
cheers
andrew
I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim thatyour package
is bsd licensed. If I were trying to use the windows
installer in a
commercial application, I sure wouldn't want that liability.
Why should we statically link it?
How well maintained is libedit? I'd feel happier about a
switch if I could find a maintained home page for it.
There appears to be more than one (!)
There's one on http://sourceforge.net/projects/libedit/, and one on
http://www.thrysoee.dk/editline/ at least. And
http://www.s11n.net/editline/. And
http://packages.qa.debian.org/e/editline.html.
The second one supports cygwin, but not mingw. The first one I have no
idea, but it has made no release since 2001 so it doesn't seem very
active, whereas the second one made a release in oct 2005. I think the
second one is the one the guy in the blog post I sent before was
referring to, but I'm not sure.
//Magnus
Import Notes
Resolved by subject fallback
Anyone for trying to port BSD libedit to work on Windows?
Maybe just let it be on Windows is acceptable. I am currently
happy with my psql without readline support on Windows, but
on Unix that's hard. If Windows users want more advanced
client, there are a bunch of GUI tools.
Well, we should *at least* provide it from the source build. Since it
does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)
If we only allow it from build-from-source, it's no different from any
other platform, license-wise.
//Magnus
Import Notes
Resolved by subject fallback
2) Should we ship a file of standard bindings. We're not
going to get it complete, but we could get some of the most
common ones in europe at least (in sweden, this would for
example include "\@£${[]}~|"). Which would help people a lot.Yes we should, at least for Windows - put it in share along
with other samples, maybe.
That was my second question on that - where to put it, and how to find it.
3) How should the inputrc file be loaded. By default, you
have to type SET INPUTRC="\some\where\inputrc" before you
launch psql. But we could just as easily add:#if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc);
#endif
to psql, making that step a whole lot easier. Especially forpeople who launch psql from the startmenu, and can't specify
program-specific env vars.if user has $HOME/inputrc
load $HOME/inputrc
elsif exists $SYSTEMCONFIG/inputrc
load $SYSTEMCONFIG/inputrc
endifSince inputrc is meant to service many applications, we
shouldn't try to bypass that.
Actually, I think readline handles that and we can't turn it off. Though I think I need to set INPUTRC=<something> to make it work on win32, it doesn't know abuot the All Users profile for example.
I was thinking of a completement to the inputrc. Which would be somethign like:
if exists $SYSTEMCONFIG/psql.inputrc
load $SYSTEMCONFIG/psql.inputrc
endif
if exists $HOME/inputrc <-- this part handled by readline, not us
laod $HOME/inputrc <-- this part handled by readline, not us
endif
//Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander writes:
2) Should we ship a file of standard bindings. We're not
going to get it complete, but we could get some of the most
common ones in europe at least (in sweden, this would for
example include "\@�${[]}~|"). Which would help people a lot.Yes we should, at least for Windows - put it in share along
with other samples, maybe.That was my second question on that - where to put it, and how to find it.
IMHO an elegant solution would be to expose readline's macro/bind
mechanism with a psql command, e.g. like bash's "bind" does. This way
one could put the macros into the system-wide psqlrc.
regards,
Andreas
Tom Lane <tgl@sss.pgh.pa.us> writes:
Robert Treat <xzilla@users.sourceforge.net> writes:
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed.Robert is 100% right.
I suspect Andrew was mixing up two different aspects of this.
There isn't much dispute that shipping a binary linked (statically or
dynamically) with a library depends on your license to distribute derivative
works of that library. Ie, that Andrew's wrong and shipping a binary linked
with a GPL'd library is only legal if you follow the terms of the GPL.
There is controversy over whether the software that requires that library
becomes a derivative work itself. For example whether a Gimp plugin that is
useless without the Gimp would be a derivative work of the Gimp itself and be
undistributable unless you followed the Gimp license terms.
Most people do agree when the question is put for something like Gimp plugins
but seem to draw a distinction between that and things like Postgres that
happen to depend on linking with libreadline where libreadline is a rather
incidental part of the whole system.
In RMS's view (and the view of the actual practicing lawyers who have examined
this question when real money was on the line, but then I guess lawyers are
paid well to have more advanced cases of paranoia than Andrew) is that there's
no such distinction in law and having software that depends on libreadline is
just as much bound by the GPL as a Gimp plugin.
But that said, in the case of a binary there's really no controversy. A binary
that's linked against libreadline clearly can't be legally distributed without
following the terms of the GPL.
--
greg
On Mon, 2 Jan 2006 16:27:48 -0600 (CST)
"Andrew Dunstan" <andrew@dunslane.net> wrote:
Our BSD license is recognised as a GPL-compatible license.
Recognized by who? The only two entities that I can think of that
matter would be GNU itself or the courts.
--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.Import Notes
Reply to msg id not found: 1706.24.211.165.134.1136240868.squirrel@www.dunslane.net
"Andrew Dunstan" <andrew@dunslane.net> writes:
The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU General
Public License, version 2. This means that if you want to use Readline in a
program that you release or distribute to anyone, the program must be free
software and have a GPL-compatible license.
Our BSD license is recognised as a GPL-compatible license.
Whoever wrote that doesn't seem to have bothered to read the GPL. The
language of the GPL is exceedingly clear and specific:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
It says THIS LICENSE. There is nothing at all about "compatible
licenses" anywhere in the document. (Quote taken directly from the copy
of the GPL in readline-4.2a.tar.gz.)
I really don't see that the Windows binary installer is any different from
the binary installers that most Linux distros have, and they are all linked
with readline.
... and they are all GPL-licensed.
The fundamental problem here is that we don't want the Windows
distribution of PG to become effectively GPL-licensed. There's no
issue if someone builds their own copy and doesn't redistribute it,
but there is a big issue if we are distributing a heavily used port
in a way that violates someone else's license.
regards, tom lane
Import Notes
Reply to msg id not found: 1706.24.211.165.134.1136240868.squirrel@www.dunslane.net
Greg Stark said:
Tom Lane <tgl@sss.pgh.pa.us> writes:
Robert Treat <xzilla@users.sourceforge.net> writes:
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
This has been debated ad nauseam in the past. The consensus, bar a
few people with more advanced paranoia than I suffer from, is that
we can ;-)I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that your package
is bsd licensed.Robert is 100% right.
I suspect Andrew was mixing up two different aspects of this.
There isn't much dispute that shipping a binary linked (statically or
dynamically) with a library depends on your license to distribute
derivative works of that library. Ie, that Andrew's wrong and shipping
a binary linked with a GPL'd library is only legal if you follow the
terms of the GPL.There is controversy over whether the software that requires that
library becomes a derivative work itself. For example whether a Gimp
plugin that is useless without the Gimp would be a derivative work of
the Gimp itself and be undistributable unless you followed the Gimp
license terms.Most people do agree when the question is put for something like Gimp
plugins but seem to draw a distinction between that and things like
Postgres that happen to depend on linking with libreadline where
libreadline is a rather incidental part of the whole system.In RMS's view (and the view of the actual practicing lawyers who have
examined this question when real money was on the line, but then I
guess lawyers are paid well to have more advanced cases of paranoia
than Andrew) is that there's no such distinction in law and having
software that depends on libreadline is just as much bound by the GPL
as a Gimp plugin.But that said, in the case of a binary there's really no controversy. A
binary that's linked against libreadline clearly can't be legally
distributed without following the terms of the GPL.
First, note that readline is ONLY used in psql. So there is no question of
GPL for most of our code.
In any case, you don't have to GPL the code, as I understand it.
The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU General
Public License, version 2. This means that if you want to use Readline in a
program that you release or distribute to anyone, the program must be free
software and have a GPL-compatible license.
Our BSD license is recognised as a GPL-compatible license.
OTOH, if I were a company distributing a closed source postgres
distribution, I would probably not link my psql with readline.
Interestingly, some Gnu software (e.g. bc) has the option of linking with
readline or libedit. It's really a pity that libedit doesn't seem to be as
well maintained.
I really don't see that the Windows binary installer is any different from
the binary installers that most Linux distros have, and they are all linked
with readline.
cheers
andrew
""Magnus Hagander"" <mha@sollentuna.net> wrote
Well, we should *at least* provide it from the source build. Since it
does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)
Yeah, I am not against doing so and having more features is always cool! But
I just suspect if we can afford the cost. Actually I tried a little bit on
the "thrysoee" version you mentioned:
$ ./config.guess
i686-pc-mingw32
$./configure
...
configure: error: libtermcap, libcurses or libncurses are required!
This may give us a hint that port is not very easy though.
Regards,
Qingqing
Tom Lane said:
"Andrew Dunstan" <andrew@dunslane.net> writes:
The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU
General Public License, version 2. This means that if you want to use
Readline in a program that you release or distribute to anyone, the
program must be free software and have a GPL-compatible license.Our BSD license is recognised as a GPL-compatible license.
Whoever wrote that doesn't seem to have bothered to read the GPL. The
language of the GPL is exceedingly clear and specific:
The page links to this: http://www.gnu.org/licenses/license-list.html which
lists the BSD licence without the advertising clause as a GPL-compatible
free software license, of which it says: "This means you can combine a
module which was released under that license with a GPL-covered module to
make one larger program."
So in the highly unlikely event that we were challenged by the FSF we could
point to that and say "we just did what your web site told us we could do."
cheers
andrew
