Re: pg_config --pgxs on Win32

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog(at)svana(dot)org]
Sent: Thu 10/13/2005 8:08 PM
To: Tom Lane
Cc: Thomas Hallgren; Dave Page; pgsql-hackers(at)postgresql(dot)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(at)svana(dot)org]
> Sent: Thu 10/13/2005 8:08 PM
> To: Tom Lane
> Cc: Thomas Hallgren; Dave Page; pgsql-hackers(at)postgresql(dot)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(at)vale-housing(dot)co(dot)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(at)svana(dot)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.

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/