From burkhard.meier@gmx.de

Created by burkhard.e.f.meier@t-online.de

This is a bug report for perl from burkhard.e.f.meier@​t-online.de,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------
"nmake install" fails on Win32 if the $(INST_TOP) makefile macro
specifies an installation directory that contains whitespace characters,
e.g.

#
# Set these to wherever you want "nmake install" to put your
# newly built perl.
#
INST_DRV = g​:
INST_TOP = $(INST_DRV)\program files\perl5.8.0

As a consequence, the makefile targets "installbare" and "installhtml"
will fail. The commands to be executed for these targets must quote
any paths to the installation directory​:

installbare : utils
$(PERLEXE) ..\installperl
if exist $(WPERLEXE) $(XCOPY) $(WPERLEXE) "$(INST_BIN)\*.*"
  ^^^^^^^^^^^^^^^^^

$(XCOPY) $(GLOBEXE) "$(INST_BIN)\*.*"
  ^^^^^^^^^^^^^^^^^
$(XCOPY) bin\*.bat "$(INST_SCRIPT)\*.*"
  ^^^^^^^^^^^^^^^^^

installhtml : doc
$(RCOPY) html\*.* "$(INST_HTML)\*.*"
  ^^^^^^^^^^^^^^^^^

instead of the current version

installbare : utils
$(PERLEXE) ..\installperl
if exist $(WPERLEXE) $(XCOPY) $(WPERLEXE) $(INST_BIN)\*.*
$(XCOPY) $(GLOBEXE) $(INST_BIN)\*.*
$(XCOPY) bin\*.bat $(INST_SCRIPT)\*.*

installhtml : doc
$(RCOPY) html\*.* $(INST_HTML)\*.*

Flags:
    category=install
    severity=low

Site configuration information for perl v5.8.0:

Configured by burkhard at Sat Sep 21 14:19:20 2002.

Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags
='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT   -DPERL_I
MPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-MD -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags
'-nologo -nodefaultlib -release  -libpath:"g:\program
files\perl5.8.0\lib\CORE"  -machine:x86'
    libpth=g:\devstudio\vc98\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib
msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib
msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version='undef'
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ',
ddlflags='-dll -nologo -nodefaultlib -release  -libpath:"g:\program
files\perl5.8.0\lib\CORE"  -machine:x86'

Locally applied patches:



@INC for perl v5.8.0:
    g:/Program Files/perl5.8.0/lib
    g:/Program Files/perl5.8.0/site/lib
    .


Environment for perl v5.8.0:
    HOME=G:/
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=g:\program files\perl5.8.0\bin;g:\program
files\perl5.8.0;G:\Perl5.6.1\bin\;g:\jdk1.1.6\bin;g:\mksnt;g:\winnt\system32
;g:\winnt;g:\winnt\system32\wbem;g:\perl\bin;g:\ultrae~1;;g:\program
files\perforce;g:\mssql7\binn;d:\ultrae~1;;G:\IXOS-ARCHIVE\OPT\FTSE\_nti40\d
ll;g:\ixos-a~1\bin;G:\IXOS-ARCHIVE\BIN;F:\IXOS\ADMS\DEBUG\BIN;F:\IXOS\ADMS\D
EBUG\LIB;G:\DEVSTUDIO\COMMON\TOOLS\WINNT;G:\DEVSTUDIO\COMMON\MSDEV98\BIN;G:\
DEVSTUDIO\COMMON\TOOLS;G:\DEVSTUDIO\VC98\BIN;G:\KAWA30;G:\SUPERC~1\Bin;G:\Pr
ogram Files\IrfanView;D:\ULTRAE~1;
    PERL_BADLANG (unset)
    SHELL=g:/mksnt/sh.exe

From @hvds

Burkhard Meier (via RT) <perlbug@​perl.org> wrote​:
:"nmake install" fails on Win32 if the $(INST_TOP) makefile macro
:specifies an installation directory that contains whitespace characters,

Thanks for the report; you suggest quoting references to $INST_BIN,
$INST_SCRIPT and $INST_HTML, but I'd have thought that many of the
other variables involved could also be space-ridden paths.

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

Hugo

From kane@cpan.org

hv@​crypt.org wrote​:

Burkhard Meier (via RT) <perlbug@​perl.org> wrote​:
:"nmake install" fails on Win32 if the $(INST_TOP) makefile macro
:specifies an installation directory that contains whitespace characters,

Thanks for the report; you suggest quoting references to $INST_BIN,
$INST_SCRIPT and $INST_HTML, but I'd have thought that many of the
other variables involved could also be space-ridden paths.

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

Hugo

I figured I'd give this a look but found that the 5.8.0 release
available on the CPAN gave the following errors during 'make test'
Forgive me if they already have been reported, but better safe than
sorry I suppose. I only changed the install dir for the Makefile, but
perl -V is still attached for clarity sake.

Perhaps someone can point me in the proper direction to contribute to a
fix for this...

###########################################################################

Failed Test Stat Wstat Total Fail Failed List of Failed

io/fs.t 32 8 25.00% 2-5 7-9 11
op/stat.t 73 2 2.74% 5 7
53 tests and 603 subtests skipped.
Failed 2/714 test scripts, 99.72% okay. 10/69111 subtests failed, 99.99%
okay.
NMAKE : fatal error U1077​: 'C​:\WINNT\system32\cmd.exe' : return code '0xff'
Stop.

io/fs..................................# Failed at io/fs.t line 92
# Failed at io/fs.t line 93
# Failed at io/fs.t line 101
# got undef
# expected '3'
# Failed at io/fs.t line 111
# got '0'
# expected '438'
# Failed at io/fs.t line 129
# got '0'
# expected '292'
# Failed at io/fs.t line 136
# got '1'
# expected '2'
# Failed at io/fs.t line 144
# got '0'
# expected '438'
# Failed at io/fs.t line 156
# got '1'
# expected '2'

op/stat................................# Failed at op/stat.t line 81
# Failed at op/stat.t line 91
# got '1'
# expected '2'
op/stat................................FAILED tests 5, 7
  Failed 2/73 tests, 97.26% okay (less 26 skipped tests​: 45 okay,
61.64%)

###########################################################################

I ran this with nmake version 1.50 on a windows 2000 machine. I still
did a 'nmake install' to get a perl -V out of it, and noticed the
following complaints as well​:

###########################################################################

....\installhtml​: ../pod/perl.pod​: cannot resolve L<xsubpp> in paragraph 56.
....\installhtml​: ../pod/perl5004delta.pod​: cannot resolve L<h2xs> in
paragraph 215.
....\installhtml​: ../pod/perl5005delta.pod​: cannot resolve L<README_vms>
in paragraph 164.
....\installhtml​: ../pod/perl572delta.pod​: cannot resolve L<libnet> in
paragraph 69.
....\installhtml​: ../pod/perl572delta.pod​: cannot resolve L<UnicodeCD> in
paragraph 93.
....\installhtml​: ../pod/perl572delta.pod​: cannot resolve L<h2ph> in
paragraph 121.
....\installhtml​: ../pod/perl572delta.pod​: cannot resolve L<h2xs> in
paragraph 123.

..... and so on ...

###########################################################################

C​:\Perl\5.8.0\bin>perl -V
Summary of my perl5 (revision 5 version 8 subversion 0) configuration​:
  Platform​:
  osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
  uname=''
  config_args='undef'
  hint=recommended, useposix=true, d_sigaction=undef
  usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=def
ine
  useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
  use64bitint=undef use64bitall=undef uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_
STRICT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_
READFIX',
  optimize='-MD -DNDEBUG -O1',
  cppflags='-DWIN32'
  ccversion='', gccversion='', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize
=4
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='link', ldflags ='-nologo -nodefaultlib -release
-libpath​:"c​:\perl\5.8.0
\lib\CORE" -machine​:x86'
  libpth=\lib
  libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
  comdlg32
...lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsoc
k32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib
  perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comd
lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib
wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
  libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
  gnulibc_version='undef'
  Dynamic Linking​:
  dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-libpath​:"c​:
\perl\5.8.0\lib\CORE" -machine​:x86'

Characteristics of this binary (from libperl)​:
  Compile-time options​: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEXT
PERL_IMP
LICIT_SYS
  Built under MSWin32
  Compiled at Sep 26 2002 23​:07​:59
  %ENV​:
  PERL5LIB="t​:/devel/lib"
  @​INC​:
  t​:/devel/lib
  C​:/Perl/5.8.0/lib
  C​:/Perl/site/5.8.0/lib
  C​:/Perl/site/lib
  .

###########################################################################

--

Jos Boumans

How do I prove I am not crazy to people who are?

CPANPLUS http​://cpanplus.sf.net
Just another perl hacker http​://japh.nu

From @schwern

On Thu, Sep 26, 2002 at 07​:19​:59PM +0100, hv@​crypt.org wrote​:

Burkhard Meier (via RT) <perlbug@​perl.org> wrote​:
:"nmake install" fails on Win32 if the $(INST_TOP) makefile macro
:specifies an installation directory that contains whitespace characters,

Thanks for the report; you suggest quoting references to $INST_BIN,
$INST_SCRIPT and $INST_HTML, but I'd have thought that many of the
other variables involved could also be space-ridden paths.

Many of them do, and it causes lots of other problems. Here's one which
causes a problem when perl is in C​:\Program Files\Perl
http​://rt.cpan.org/NoAuth/Bug.html?id=448

It can't be fixed because there's currently no reliable way to bypass the
shell and still trap the output of a system command.

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

To fix it properly, I think the whole of MakeMaker will have to be swept for
this sort of thing. It likely effects Unix as well, only we tend to avoid
spaces in paths under Unix.

--

Michael G. Schwern <schwern@​pobox.com> http​://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@​perl.org> Kwalitee Is Job One
Worship the sig file

From @jkeenan

On Fri Sep 27 17​:28​:09 2002, schwern wrote​:

On Thu, Sep 26, 2002 at 07​:19​:59PM +0100, hv@​crypt.org wrote​:

Burkhard Meier (via RT) <perlbug@​perl.org> wrote​:
:"nmake install" fails on Win32 if the $(INST_TOP) makefile macro
:specifies an installation directory that contains whitespace
characters,

Thanks for the report; you suggest quoting references to $INST_BIN,
$INST_SCRIPT and $INST_HTML, but I'd have thought that many of the
other variables involved could also be space-ridden paths.

Many of them do, and it causes lots of other problems. Here's one which
causes a problem when perl is in C​:\Program Files\Perl
http​://rt.cpan.org/NoAuth/Bug.html?id=448

It can't be fixed because there's currently no reliable way to bypass the
shell and still trap the output of a system command.

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

To fix it properly, I think the whole of MakeMaker will have to be
swept for
this sort of thing. It likely effects Unix as well, only we tend to avoid
spaces in paths under Unix.

ISTR that these questions of whitespace in paths come up from time to
time. Is there someone out there who is familiar with those issues who
could review this ticket and make a recommendation?

Thank you very much.
Jim Keenan

From @nwc10

On Thu, Sep 27, 2012 at 06​:44​:12PM -0700, James E Keenan via RT wrote​:

On Fri Sep 27 17​:28​:09 2002, schwern wrote​:

On Thu, Sep 26, 2002 at 07​:19​:59PM +0100, hv@​crypt.org wrote​:

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

To fix it properly, I think the whole of MakeMaker will have to be
swept for
this sort of thing. It likely effects Unix as well, only we tend to avoid
spaces in paths under Unix.

ISTR that these questions of whitespace in paths come up from time to
time. Is there someone out there who is familiar with those issues who
could review this ticket and make a recommendation?

I think that Schwern has already expressed the scale of the problem.
It's tricky to fix because

1) most of the text-based toolchain makes the assumption that whitespace
  separates parameter names. And specifically is not "just in the middle"
  of a single parameter
2) there is often more than one level of interpolation going on
3) different interpolation layers might have different (or the same)
  escaping rules
4) one really needs to be adding the encoding at the point of crossing a
  boundary (ie not storing filenames internally as "/foo/bar\ baz")
5) On Win32 in particular, I'm not sure if the quoting rules are consistent
  between the various shells you might find. At least under *nix, quoting for
  /bin/sh (and derivatives) is well defined.

As is, I think that if there is an order to tackle this, it's

1) Perl can't be installed to a path with spaces in it
2) That installed perl can't be used to build pure-perl extensions
3) That installed perl can't be used to build XS extensions
4) Perl can't be built from source in a path with spaces in it

Steps (2) and (3) are the ones that end users would hit, but you can't
actually fix those until you solve step (1). Step (4) is a nice to have, but
is the least important to fix. Most people aren't building perl from source,
and if they are, they will likely have control over the pathname they use.

So I think, possibly, create a meta-ticket for each of the 4 categories,
attach bugs to each, and possibly also drop the priority to "wishlist",
because I don't forsee this getting fixed any time soon.

Nicholas Clark

From @nwc10

On Thu, Sep 27, 2012 at 06​:44​:12PM -0700, James E Keenan via RT wrote​:

On Fri Sep 27 17​:28​:09 2002, schwern wrote​:

On Thu, Sep 26, 2002 at 07​:19​:59PM +0100, hv@​crypt.org wrote​:

Can any win32 expert confirm how much needs to change here? (Preferably
with a patch. :)

To fix it properly, I think the whole of MakeMaker will have to be
swept for
this sort of thing. It likely effects Unix as well, only we tend to avoid
spaces in paths under Unix.

ISTR that these questions of whitespace in paths come up from time to
time. Is there someone out there who is familiar with those issues who
could review this ticket and make a recommendation?

I think that Schwern has already expressed the scale of the problem.
It's tricky to fix because

1. most of the text-based toolchain makes the assumption that whitespace
   separates parameter names. And specifically is not "just in the middle"
   of a single parameter
2. there is often more than one level of interpolation going on
3. different interpolation layers might have different (or the same)
   escaping rules
4. one really needs to be adding the encoding at the point of crossing a
   boundary (ie not storing filenames internally as "/foo/bar\ baz")
5. On Win32 in particular, I'm not sure if the quoting rules are consistent
   between the various shells you might find. At least under *nix, quoting for
   /bin/sh (and derivatives) is well defined.

As is, I think that if there is an order to tackle this, it's

1. Perl can't be installed to a path with spaces in it
2. That installed perl can't be used to build pure-perl extensions
3. That installed perl can't be used to build XS extensions
4. Perl can't be built from source in a path with spaces in it

Steps (2) and (3) are the ones that end users would hit, but you can't
actually fix those until you solve step (1). Step (4) is a nice to have, but
is the least important to fix. Most people aren't building perl from source,
and if they are, they will likely have control over the pathname they use.

So I think, possibly, create a meta-ticket for each of the 4 categories,
attach bugs to each, and possibly also drop the priority to "wishlist",
because I don't forsee this getting fixed any time soon.

Nicholas Clark

This ticket was opened in 2002 and last commented upon in 2013. My take: while there is a general problem in building perl and its extensions on paths that contain whitespace, it's a problem which one particular OS largely inflicts upon itself. Consequently, it shouldn't be a high or low priority for Perl 5 Porters; we have bigger fish to fry.

If anyone wants to tackle this problem, he or she is welcome to open new issues along the lines of the 4-step process @nwc10 outlined eight years ago. In the meantime, I plan to close this ticket within 7 days unless someone provides a strong reason for keeping it open.

Thank you very much.
Jim Keenan

If anyone wants to tackle this problem, he or she is welcome to open new issues along the lines of the 4-step process @nwc10 outlined eight years ago. In the meantime, I plan to close this ticket within 7 days unless someone provides a strong reason for keeping it open.

Closing as per schedule.