Re: make fails if path has spaces

Andreas Pflug wrote:
> If configure detects some tools in the existing path, the build process
> may fail.
> In my case, there's perl under c:\program files. make will fail while in
> bin/psql because "/c/program" is not found.

I am not surprised. We do not do proper quoting of environment
variables in configure.in. I also don't know if the autoconf program
that creates the configure output does proper quoting either. Can you
tell us where it is failing by looking in config.log?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

If configure detects some tools in the existing path, the build process
may fail.
In my case, there's perl under c:\program files. make will fail while in
bin/psql because "/c/program" is not found.

Regards,
Andreas

Bruce Momjian wrote:
> Andreas Pflug wrote:
>
>>If configure detects some tools in the existing path, the build process
>>may fail.
>>In my case, there's perl under c:\program files. make will fail while in
>>bin/psql because "/c/program" is not found.
>
>
> I am not surprised. We do not do proper quoting of environment
> variables in configure.in. I also don't know if the autoconf program
> that creates the configure output does proper quoting either. Can you
> tell us where it is failing by looking in config.log?

I'm no sure what you mean. AFAICS configure does detect the program
location all right, but it should either omit the full path, so the
program is located using $PATH, or executables found should be quoted.

Regards,
Andreas

Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
> >>If configure detects some tools in the existing path, the build process
> >>may fail.
> >>In my case, there's perl under c:\program files. make will fail while in
> >>bin/psql because "/c/program" is not found.
> >
> >
> > I am not surprised. We do not do proper quoting of environment
> > variables in configure.in. I also don't know if the autoconf program
> > that creates the configure output does proper quoting either. Can you
> > tell us where it is failing by looking in config.log?
>
> I'm no sure what you mean. AFAICS configure does detect the program
> location all right, but it should either omit the full path, so the
> program is located using $PATH, or executables found should be quoted.

Yes, the executable has to be quoted. Where is it being referenced
unquoted?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>
> Yes, the executable has to be quoted. Where is it being referenced
> unquoted?

In this case, $(PERL) is referenced for building psql's doc. PERL is set
in Makefile.global unquoted, as all paths.

For others, the same problem might arise with bison or flex.

Regards,
Andrea

Has anyone tried Point in Time recovery on Win32? tried to set it up
today and keep getting this error

*Test=# Select pg_start_backup('test backup');
ERROR: function pg_start_backup("unknown") does not exist
HINT: No function matches the given name and argument types. You may
need to add explicit type casts
*
--
*Jamie Deppeler
*

Jamie Deppeler <jamie(at)doitonce(dot)net(dot)au> writes:
> Has anyone tried Point in Time recovery on Win32? tried to set it up
> today and keep getting this error

> *Test=# Select pg_start_backup('test backup');
> ERROR: function pg_start_backup("unknown") does not exist

I just committed that function late this afternoon ... how old is
the snapshot you're using?

regards, tom lane

Andreas Pflug wrote:

> Bruce Momjian wrote:
>
>>
>> Yes, the executable has to be quoted. Where is it being referenced
>> unquoted?
>
>
> In this case, $(PERL) is referenced for building psql's doc. PERL is
> set in Makefile.global unquoted, as all paths.
>
> For others, the same problem might arise with bison or flex.
>
>

Generally I think we expect all the build tools to be installed under
MSys - maybe you need to install MSysDTK?

An alternative would be to quote $(PERL) in psql's Makefile, but that
might not solve the general problem, as you observe.

cheers

andrew

Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> > Yes, the executable has to be quoted. Where is it being referenced
> > unquoted?
>
> In this case, $(PERL) is referenced for building psql's doc. PERL is set
> in Makefile.global unquoted, as all paths.
>
> For others, the same problem might arise with bison or flex.

Is the problem the assignment in Makefile.global or the use of the
variable in psql/Makefile?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
> Andreas Pflug wrote:
>
>>Bruce Momjian wrote:
>>
>>
>>>Yes, the executable has to be quoted. Where is it being referenced
>>>unquoted?
>>
>>In this case, $(PERL) is referenced for building psql's doc. PERL is set
>>in Makefile.global unquoted, as all paths.
>>
>>For others, the same problem might arise with bison or flex.
>
>
> Is the problem the assignment in Makefile.global or the use of the
> variable in psql/Makefile?
>

It could be fixed in both places, but the more general fix would be to
qoute in Makefile.global, i.e. fixing configure.

Regards,
Andreas

Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Andreas Pflug wrote:
> >
> >>Bruce Momjian wrote:
> >>
> >>
> >>>Yes, the executable has to be quoted. Where is it being referenced
> >>>unquoted?
> >>
> >>In this case, $(PERL) is referenced for building psql's doc. PERL is set
> >>in Makefile.global unquoted, as all paths.
> >>
> >>For others, the same problem might arise with bison or flex.
> >
> >
> > Is the problem the assignment in Makefile.global or the use of the
> > variable in psql/Makefile?
> >
>
> It could be fixed in both places, but the more general fix would be to
> qoute in Makefile.global, i.e. fixing configure.

What if you change this:

PERL = @PERL@

to this:

PERL = "@PERL@"

Does it help?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>>>
>>
>>It could be fixed in both places, but the more general fix would be to
>>qoute in Makefile.global, i.e. fixing configure.
>
>
> What if you change this:
>
> PERL = @PERL@
>
> to this:
>
> PERL = "@PERL@"
>
> Does it help?
>

Changed in src/Makefile.global.in, and it works.
There are other candidates that could have a non-msys path, which maybe
should be quoted as well.

Regards,
Andreas

OK, patch attached and applied. I am not sure if there are going to be
other place that need fixing so I added a comment.

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

Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >>>
> >>
> >>It could be fixed in both places, but the more general fix would be to
> >>qoute in Makefile.global, i.e. fixing configure.
> >
> >
> > What if you change this:
> >
> > PERL = @PERL@
> >
> > to this:
> >
> > PERL = "@PERL@"
> >
> > Does it help?
> >
>
> Changed in src/Makefile.global.in, and it works.
> There are other candidates that could have a non-msys path, which maybe
> should be quoted as well.
>
> Regards,
> Andreas
>
>
> ---------------------------(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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073