Обсуждение: pg_config --pgxs on Win32

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

export PGXS := $(dir $(shell pg_config --pgxs))

and now it yields "./"

I tried to do the following:

$(warning "PGXS = $(dir c:\\msys\\local\\pgsql\\lib\\pgxs\\src\\MAKEFI~1\\pgxs.mk)")
$(warning "PGXS = $(dir c:/msys/local/pgsql/lib/pgxs/src/MAKEFI~1\\pgxs.mk)")

The first one yields "./", the second is OK.

I guess it happened when changing to using short-name represenation?

Regards,
Thomas Hallgren

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
ormay 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
mayor 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/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Dave Page wrote:

>We should probably document that pg_config may not work reliably with non-mingw tools in that case. Microsoft code may
ormay 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
canbe 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
thatpg_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
canbe 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
docsthat 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/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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