Re: make fails if path has spaces

Started by Bruce Momjianalmost 22 years ago12 messagespatches
Jump to latest
#1Bruce Momjian
bruce@momjian.us

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#2Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#1)

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

#3Bruce Momjian
bruce@momjian.us
In reply to: Andreas Pflug (#2)

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#4Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#3)

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

#5Jamie Deppeler
jamie@doitonce.net.au
In reply to: Bruce Momjian (#3)
Point in Time Recovery

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
*

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jamie Deppeler (#5)
Re: Point in Time Recovery

Jamie Deppeler <jamie@doitonce.net.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

#7Andrew Dunstan
andrew@dunslane.net
In reply to: Andreas Pflug (#4)

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

#8Bruce Momjian
bruce@momjian.us
In reply to: Andreas Pflug (#4)

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#9Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#8)

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

#10Bruce Momjian
bruce@momjian.us
In reply to: Andreas Pflug (#9)

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#11Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#10)

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

#12Bruce Momjian
bruce@momjian.us
In reply to: Andreas Pflug (#11)

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Attachments:

/bjm/difftext/plainDownload+2-2