pg_config --pgxs on Win32

Thomas Hallgren <thhal@mailblocks.com> writes:

Something changed very recently in the output from pg_config --pgxs
command on Win32. It now outputs double backslash everywhere instead
of forward slashes. The mingw GNU Make is not too happy about the
double backslashes.

I said that was a bad idea when it was done. I'll undo it.

regards, tom lane

-----Original Message-----
From: "Tom Lane"<tgl@sss.pgh.pa.us>
Sent: 13/10/05 18:23:13
To: "Thomas Hallgren"<thhal@mailblocks.com>
Cc: "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] pg_config --pgxs on Win32

The mingw GNU Make is not too happy about the
double backslashes.

I said that was a bad idea when it was
done. I'll undo it.

We should probably document that pg_config may not work reliably with non-mingw tools in that case. Microsoft code may or may not do what is expected with front slashes.

BTW Thomas - I thought you said \\ did work when you were testing options for me, or was that just msys rather than make?

Regards, Dave

-----Unmodified Original Message-----
Thomas Hallgren <thhal@mailblocks.com> writes:

Something changed very recently in the output from pg_config --pgxs
command on Win32. It now outputs double backslash everywhere instead
of forward slashes. The mingw GNU Make is not too happy about the
double backslashes.

I said that was a bad idea when it was done. I'll undo it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Dave Page wrote:

We should probably document that pg_config may not work reliably with non-mingw tools in that case. Microsoft code may or may not do what is expected with front slashes.

BTW Thomas - I thought you said \\ did work when you were testing options for me, or was that just msys rather than make?

That was when testing different paths in the Makefile.global. Apparenlty
a make never does a $(dir xxx) on those paths.

I do have a workaround in place that makes it work for me now. I do
$(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
platform for pgxs on Win32 is MinGW, perhaps it should output forward
slashes anyway. Hmm, then again, perhaps only PL/Java does a $(dir xxx)
on the output.

Regards,
Thomas Hallgren

Thomas Hallgren <thhal@mailblocks.com> writes:

I do have a workaround in place that makes it work for me now. I do
$(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
platform for pgxs on Win32 is MinGW, perhaps it should output forward
slashes anyway.

I've already applied that change. Your gripe was pretty much exactly
what I was afraid we'd hear, namely that the double-backslash output
would break cases that used to work. I think we should stick with the
forward slash output, since that's what we know has been working in the
8.0 branch.

regards, tom lane

On Thu, Oct 13, 2005 at 02:53:09PM -0400, Tom Lane wrote:

Thomas Hallgren <thhal@mailblocks.com> writes:

I do have a workaround in place that makes it work for me now. I do
$(dir $(subst \\,/,xxx)) and that works fine but given that the targeted
platform for pgxs on Win32 is MinGW, perhaps it should output forward
slashes anyway.

I've already applied that change. Your gripe was pretty much exactly
what I was afraid we'd hear, namely that the double-backslash output
would break cases that used to work. I think we should stick with the
forward slash output, since that's what we know has been working in the
8.0 branch.

Besides, Windows has accepted the forward slash as directory seperator
all the way since DOS 2.0 when directories were introduced. The only
reason they sometimes don't work as expected is because it's also the
option indicator :(.

Presumably things break when commands read /path as an option rather
than a path. Hopefully they're smart enough to realize c:/path does not
actually contain an option but is just a path. Presumably that's
fixable some other way?
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Dave Page wrote:

We should probably document that pg_config may not work reliably with non-mingw tools in that case. Microsoft code may or may not do what is expected with front slashes.

BTW Thomas - I thought you said \\ did work when you were testing options for me, or was that just msys rather than make?

My recollection from building libpq and pg_config using MSVC command
line tools for DBD::Pg is that forward slashes worked just fine. If it
doesn't then we should document fairly specifically where.

cheers

andrew

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32

Besides, Windows has accepted the forward slash as directory seperator
all the way since DOS 2.0 when directories were introduced. The only
reason they sometimes don't work as expected is because it's also the
option indicator :(.

Presumably things break when commands read /path as an option rather
than a path. Hopefully they're smart enough to realize c:/path does not
actually contain an option but is just a path. Presumably that's
fixable some other way?

When we first discussed this I posted a very simple example 'cd /' which does absolutely nothing unlike 'cd \' or 'cd \\' which work as expected, quite possibly for the reason you suggest. Although the / is accepted, I don't believe it can be called reliable as it obviously doesn't work in all situations.

Regardless, the msys/gmake case is definately the most important to support, but I do think we should note in the docs that pg_config may not work well in non-msys/cygwin environments.

Regards, dave.

Dave Page wrote:

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32

Besides, Windows has accepted the forward slash as directory seperator
all the way since DOS 2.0 when directories were introduced. The only
reason they sometimes don't work as expected is because it's also the
option indicator :(.

Presumably things break when commands read /path as an option rather
than a path. Hopefully they're smart enough to realize c:/path does not
actually contain an option but is just a path. Presumably that's
fixable some other way?

When we first discussed this I posted a very simple example 'cd /' which does absolutely nothing unlike 'cd \' or 'cd \\' which work as expected, quite possibly for the reason you suggest. Although the / is accepted, I don't believe it can be called reliable as it obviously doesn't work in all situations.

Regardless, the msys/gmake case is definately the most important to support, but I do think we should note in the docs that pg_config may not work well in non-msys/cygwin environments.

Regards, dave.

Perhaps pg_config should have a --pgxscanonical option? If someone then
really wants the backslashes, he could use that.

- thomas

"Dave Page" <dpage@vale-housing.co.uk> writes:

When we first discussed this I posted a very simple example 'cd /'
which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
expected, quite possibly for the reason you suggest. Although the / is
accepted, I don't believe it can be called reliable as it obviously
doesn't work in all situations.

However, that's not the issue here. AFAIK, pg_config will only put out
fully qualified paths, that is "C:/foo", so the risk that something
starting with slash will be misinterpreted seems irrelevant to me.

If it doesn't always prepend a drive letter, let's see about fixing
that instead.

regards, tom lane

On Thu, Oct 13, 2005 at 08:36:39PM +0100, Dave Page wrote:

When we first discussed this I posted a very simple example 'cd /'
which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
expected, quite possibly for the reason you suggest. Although the /
is accepted, I don't believe it can be called reliable as it
obviously doesn't work in all situations.

Indeed, what you are seeing there is cmd.exe (or whatever it's called)
command-line parsing. The same issue applies to any builtin commands
such as echo. Once you start executing external commands, they are
responsible for their own command-line parsing.

So, we need examples of other programs that behave differently when
given complete paths with forward slashes (such as c:/windows/system).
For example, the Visual C++ compiler explicitly states it takes
filenames with either forward or backslashes. Commands built into
cmd.exe tend to be strange in this way, although programs ported from
UNIX will probably work fine.

I don't see an easy way out. Half the system thinks backslashes are
special and need expansion, the other half thinks forward slashes are
option markers. This is really just a variation on the "space in
filenames" issue in UNIX.

Unfortunatly, Windows never had a getopt and so there is no standard
way of dealing with options. Every program does it differently. For
example, there is no "end of options" marker, which is how you would
deal with this issue in UNIX.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 13 October 2005 20:41
To: Dave Page
Cc: Martijn van Oosterhout; Thomas Hallgren;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32

"Dave Page" <dpage@vale-housing.co.uk> writes:

When we first discussed this I posted a very simple example 'cd /'
which does absolutely nothing unlike 'cd \' or 'cd \\' which work as
expected, quite possibly for the reason you suggest.

Although the / is

accepted, I don't believe it can be called reliable as it obviously
doesn't work in all situations.

However, that's not the issue here. AFAIK, pg_config will
only put out
fully qualified paths, that is "C:/foo", so the risk that something
starting with slash will be misinterpreted seems irrelevant to me.

If it doesn't always prepend a drive letter, let's see about fixing
that instead.

Won't help:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dpage>mkdir c:\foo

C:\Documents and Settings\dpage>cd c:/foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd /foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd c:\foo

C:\foo>

Regards, Dave

On 10/14/05, Dave Page <dpage@vale-housing.co.uk> wrote:

Won't help:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dpage>mkdir c:\foo

C:\Documents and Settings\dpage>cd c:/foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd /foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd c:\foo

C:\foo>

Regards, Dave

Can't prepend a drive name anyways with 'cd', what if you're on a
different drive?

=Win2kpro=====================
E:\>cd "c:/Test"
The system cannot find the path specified.

E:\>c:

C:\Test>cd "/Test"
The syntax of the command is incorrect.

C:\Test>cd /
The syntax of the command is incorrect.

C:\Test>cd "c:/"

C:\Test>cd \

C:\>cd "/Test"
The syntax of the command is incorrect.

C:\>cd "Test/Test2"

C:\Test\Test2>

--
Christopher A. Watford
christopher.watford@gmail.com

-----Original Message-----
From: Christopher A. Watford [mailto:christopher.watford@gmail.com]
Sent: 14 October 2005 15:58
To: Dave Page
Cc: Tom Lane; Martijn van Oosterhout; Thomas Hallgren;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config --pgxs on Win32

On 10/14/05, Dave Page <dpage@vale-housing.co.uk> wrote:

Won't help:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dpage>mkdir c:\foo

C:\Documents and Settings\dpage>cd c:/foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd /foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd c:\foo

C:\foo>

Regards, Dave

Can't prepend a drive name anyways with 'cd', what if you're on a
different drive?

Yes you can, windows remembers a current directory for each drive so:

D:\>c:

C:\>cd d:\music

C:\>d:

D:\Music>

That's not really the issue though - it was pointed out that pg_config
always includes the drive unlike my previous example so I was just
pointing out that it doesn't always work with the drive either.

Regards, Dave.

On 10/14/05, Dave Page <dpage@vale-housing.co.uk> wrote:

Won't help:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\dpage>mkdir c:\foo

C:\Documents and Settings\dpage>cd c:/foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd /foo
The system cannot find the path specified.

C:\Documents and Settings\dpage>cd c:\foo

C:\foo>

Regards, Dave

Can't prepend a drive name anyways with 'cd', what if you're on a
different drive?

=Win2kpro=====================
E:\>cd "c:/Test"
The system cannot find the path specified.

Try "cd /D c:/Test"

The /D option changes the current directory *and* the current drive in one
command.

--
Matt Emmerton

Martijn van Oosterhout wrote:

I don't see an easy way out. Half the system thinks backslashes are
special and need expansion, the other half thinks forward slashes are
option markers. This is really just a variation on the "space in
filenames" issue in UNIX.

pg_config --pgxs is supposed to be included from a makefile, and while
GNU make supports command.com/cmd.exe to be the underlying shell of a
make process, it's unlikely that our makefiles do, so you need a
Unix-style shell anyway, so the forward slashes are not a problem.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/