From @kmx

Created by @kmx

Hi,

I have a kind of objection to using "space" as item separator in
$Config{libpth} value.

The trouble occurs when any it the libpth item already contains
"space". For example on my Strawberry perl $Config{libpth} looks
like this​:

D​:\strawberry512\c\lib D​:\strawberry512\c\i686-w64-mingw32\lib

And as you can guess if any of the directories contains a space
in its name things break.

I have two suggestions​:

1/ using $Config{path_sep} as a separator for $Config{libpth} value
(not backward compatible)

2/ creating a new item $Config{libpth...} which value will be
constructed in way friendly to dirnames with spaces

Any feedback welcome

--
kmx

Flags:
    category=library
    severity=low
    module=Config

Site configuration information for perl 5.12.0:

Configured by 1 at Thu May  6 16:22:52 2010.

Summary of my perl5 (revision 5 version 12 subversion 0) configuration:
   
  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname='Win32 strawberryperl 5.12.0.1 #1 Thu May  6 16:09:27 2010 i386'
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT 
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='4.4.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long
long', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -L"D:\strawberry512\perl\lib\CORE"
-L"D:\strawberry512\c\lib"'
    libpth=D:\strawberry512\c\lib D:\strawberry512\c\i686-w64-mingw32\lib
    libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool
-lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid
-lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    libc=, so=dll, useshrplib=true, libperl=libperl512.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -s
-L"D:\strawberry512\perl\lib\CORE" -L"D:\strawberry512\c\lib"'

Locally applied patches:
    


@INC for perl 5.12.0:
    D:/strawberry512/perl/site/lib
    D:/strawberry512/perl/vendor/lib
    D:/strawberry512/perl/lib
    .


Environment for perl 5.12.0:
    HOME=C:\Users\kmx
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
   
PATH=D:\strawberry512\perl\site\bin;D:\strawberry512\perl\bin;D:\strawberry512\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
    PERL_BADLANG (unset)
    PERL_MM_USE_DEFAULT=1
    SHELL (unset)

From @doughera88

On Sun, 18 Jul 2010, kmx wrote​:

# New Ticket Created by kmx
# Please include the string​: [perl #76558]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=76558 >

This is a bug report for perl from kmx@​volny.cz,
generated with the help of perlbug 1.39 running under perl 5.12.0.

-----------------------------------------------------------------
[Please describe your issue here]

Hi,

I have a kind of objection to using "space" as item separator in
$Config{libpth} value.

The trouble occurs when any it the libpth item already contains
"space". For example on my Strawberry perl $Config{libpth} looks
like this​:

D​:\strawberry512\c\lib D​:\strawberry512\c\i686-w64-mingw32\lib

And as you can guess if any of the directories contains a space
in its name things break.

Yes, many spots in perl's Configure assume directory names don't contain
spaces. However, I'm curious. Does Strawberry perl actually use
Configure? If so, I'd be amazed if this was the only thing that broke.
If not, what is using $Config{libpth} that ends up breaking?

I have two suggestions​:

1/ using $Config{path_sep} as a separator for $Config{libpth} value
(not backward compatible)

Since that's not backward compatible, I'd rather not go that route.

2/ creating a new item $Config{libpth...} which value will be
constructed in way friendly to dirnames with spaces

That sounds sensible, but is this the only variable for which this has
been an issue for you? (It would be nice to understand the full scope of
the problem before contemplating ad-hoc workarounds.)

Thanks,

--
  Andy Dougherty doughera@​lafayette.edu

The RT System itself - Status changed from 'new' to 'open'

From @csjewell

Andy, right now, we have to program in a restriction to Strawberry
Perl's installer that it can't be installed in directories with spaces,
_partly_ because of this and other values in %Config that make
assumptions of space-separation like this.

We (kmx and I) would like to be able to get rid of that restriction, if
we can, and this is one step toward doing so.

To answer your question, no, the equivalent of the 'configure' script is
hard-coded into the build as win32\config.* and config_H.* and those
files need to be edited before building as required. These variables are
still _used_ on Win32, of course. I'd have to check and see if there
were any other config variables that make this assumption (I'm not
feeling well this afternoon to do it myself, and I've got to catch up on
RL chores.)

And yes, I agree with you in thinking what kmx proposed as option 2
(defining new %Config values that are separated by something else) is
the better one.

kmx​: I think the next step would be to determine what other variables
are currently space separated and shouldn't be - could you post a list
to this bug, please?

--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

From @kmx

Dne 19.7.2010 19​:43, Andy Dougherty via RT napsal(a)​:

On Sun, 18 Jul 2010, kmx wrote​:

Hi,

I have a kind of objection to using "space" as item separator in
$Config{libpth} value.

The trouble occurs when any it the libpth item already contains
"space". For example on my Strawberry perl $Config{libpth} looks
like this​:

D​:\strawberry512\c\lib D​:\strawberry512\c\i686-w64-mingw32\lib

And as you can guess if any of the directories contains a space
in its name things break.

Yes, many spots in perl's Configure assume directory names don't contain
spaces. However, I'm curious. Does Strawberry perl actually use
Configure? If so, I'd be amazed if this was the only thing that broke.
If not, what is using $Config{libpth} that ends up breaking?

The troubles do not happen during perl configure/build (see comments by
Curtis in his post). The problems occurs when using some modules
operating with $Config{libpth}.

The most critical is ExtUtils​::MM|Liblist|CBuilder (I do not know which
one exactly) when looking for available *.a|*.lib libraries according to
$Config{libpth} value. In the end it prevents building some (not all) XS
modules, which is not good. I have also come across a couple of other
modules doing something like​: my @​libdirs = split(' ', $Config{libpth});

I do not blame those modules as currently there is no easy way how to
"decode" $Config{libpth} value correctly if some of the directories
contains a "space".

I have two suggestions​:

1/ using $Config{path_sep} as a separator for $Config{libpth} value
(not backward compatible)

Since that's not backward compatible, I'd rather not go that route.

OK.

2/ creating a new item $Config{libpth...} which value will be
constructed in way friendly to dirnames with spaces

That sounds sensible, but is this the only variable for which this has
been an issue for you? (It would be nice to understand the full scope of
the problem before contemplating ad-hoc workarounds.)

I'll do a research on all other variables to check for the same issue.

Thanks for feedback.

--
kmx

From @sisyphus

----- Original Message -----
From​: "kmx" <kmx@​volny.cz>

I do not blame those modules as currently there is no easy way how to
"decode" $Config{libpth} value correctly if some of the directories
contains a "space".

Not that I'm suggesting it's an "easy way" to decode the correct value (and
you're probably already aware of this), but you do have the "C​:" (or, more
generally, "[a-z,A-Z]​:") to anchor the position where a directory name
starts. That is, you know that from one "C​:" to the next, you have a
directory name, irrespective of how many spaces there are in that interval.

Hmmm ... actually, I've just assumed something that I don't know to be so.
I've never seen a $Config{libpth} where the various directories contain
spaces, so I shouldn't take it for granted that it's as I imagine it would
be.

I guess another solution would be to have $Config{libpth} populated with the
short pathname (as returned by Win32​::GetShortPathName, eg).

Cheers,
Rob

From @csjewell

On Tue Jul 20 02​:26​:40 2010, sisyphus1@​optusnet.com.au wrote​:

I guess another solution would be to have $Config{libpth} populated
with the
short pathname (as returned by Win32​::GetShortPathName, eg).

Except for the fact that GetShortPathName() is not guaranteed to return
a sane short path name - for example, you can turn off short name
generation on an NTFS partition. Why, I don't know, but you could. Then
it'd error out.

Note Not all file systems follow the tilde substitution convention, and
systems can be configured to disable 8.3 alias generation even if they
normally support it. Therefore, do not make the assumption that the 8.3
alias already exists on-disk. (Quoted from
http​://msdn.microsoft.com/en-us/library/aa365247%28v=VS.85%29.aspx )

From @b2gills

On Tue, Jul 20, 2010 at 4​:24 AM, Sisyphus <sisyphus1@​optusnet.com.au> wrote​:

----- Original Message ----- From​: "kmx" <kmx@​volny.cz>

I do not blame those modules as currently there is no easy way how to
"decode" $Config{libpth} value correctly if some of the directories
contains a "space".

Not that I'm suggesting it's an "easy way" to decode the correct value (and
you're probably already aware of this), but you do have the "C​:" (or, more
generally, "[a-z,A-Z]​:") to anchor the position where a directory name
starts. That is, you know that from one "C​:" to the next, you have a
directory name, irrespective of how many spaces there are in that interval.

Hmmm ... actually, I've just assumed something that I don't know to be so.
I've never seen a $Config{libpth} where the various directories contain
spaces, so I shouldn't take it for granted that it's as I imagine it would
be.

I guess another solution would be to have $Config{libpth} populated with the
short pathname (as returned by Win32​::GetShortPathName, eg).

There is are some potential problems with using the short name.
You can't reliably copy files from one computer to another.
It's also possible to rename folders, and having the short name
changed to something different.

In other words, it isn't nearly as reliable as just having a path
without any spaces.

From @sisyphus

----- Original Message -----
From​: "Brad Gilbert" <b2gills@​gmail.com>

I guess another solution would be to have $Config{libpth} populated with
the
short pathname (as returned by Win32​::GetShortPathName, eg).

There is are some potential problems with using the short name.
You can't reliably copy files from one computer to another.
It's also possible to rename folders, and having the short name
changed to something different.

I don't see the relevance of that wrt building perl from source, or wrt the
tasks that the Strawberry installer must perform. (I'm not boldly asserting
that there is no relevance - just, literally, that I don't see it.)

Mind you, I'm not even sure that my contribution to this thread contains
anything relevant to that either :-)

From the point of view of building perl from source (on a machine where
CCLIBDIR and EXTRALIBDIRS contain spaces), I think that if the short name
for CCLIBDIR and EXTRALIBDIRS was entered into the makefile.mk then
everything would be fine. But I don't care enough about this to actually
check. Note that CCLIBDIR and EXTRALIBDIRS need to be configured by the user
anyway - the only extra burden would be to enter the short name instead of
the usual long name.

And from the point of view of the Strawberry installer, I was envisaging
that it would be not too difficult to have the installer re-write
$Config{libpth} with short names when installing Strawberry into a directory
that contained spaces. Again, there's no guarantee that my assumption is
correct. Note that the installer (or post-install script) is going to have
to rewrite $Config{libpth} anyway.

In other words, it isn't nearly as reliable as just having a path
without any spaces.

Yes, and it amazes me that people still put stuff in paths containing
spaces. I find it even more amazing that (many) developers then bust their
guts to accommodate that practice !!

Cheers,
Rob

From @kmx

2/ creating a new item $Config{libpth...} which value will be
constructed in way friendly to dirnames with spaces

That sounds sensible, but is this the only variable for which this
has been an issue for you? (It would be nice to understand the
full scope of the problem before contemplating ad-hoc workarounds.)

I'll do a research on all other variables to check for the same issue.

Here are the result of my research - at least the following %Config
items are not friendly with spaces in dirnames (or filenames)​:

libpth
glibpth
libsdirs
libsfound
libspath
locincpth
loclibpth
timeincl
xlibpth
plibpth

I have analysed 5.12.3 and the problem seem to be wider than just
$Config{libpth}.

Perhaps the beginning of 5.15/5.16 era is a good point to make changes
that somehow handle this RT.

--
kmx

From @markdootson

Hi,

Isn't this already handled by simply providing the paths in the format
the os expects?

e.g. If I want to use a mingw compiler on Windows and set the libpth
appropriately, I use

libpth => qq(\"$pathtomingw\\lib\" \"$pathtomingw\\$archlib\\lib\")

or am I missing something deeper? (very possible)

On 10/05/2011 01​:14, kmx via RT wrote​:

2/ creating a new item $Config{libpth...} which value will be
constructed in way friendly to dirnames with spaces

That sounds sensible, but is this the only variable for which this
has been an issue for you? (It would be nice to understand the
full scope of the problem before contemplating ad-hoc workarounds.)

I'll do a research on all other variables to check for the same issue.

Here are the result of my research - at least the following %Config
items are not friendly with spaces in dirnames (or filenames)​:

libpth
glibpth
libsdirs
libsfound
libspath
locincpth
loclibpth
timeincl
xlibpth
plibpth

I have analysed 5.12.3 and the problem seem to be wider than just
$Config{libpth}.

Perhaps the beginning of 5.15/5.16 era is a good point to make changes
that somehow handle this RT.

--
kmx

From @kmx

Dne 10.5.2011 16​:51, Mark Dootson napsal(a)​:

Hi,

Isn't this already handled by simply providing the paths in the format
the os expects?

e.g. If I want to use a mingw compiler on Windows and set the libpth
appropriately, I use

libpth => qq(\"$pathtomingw\\lib\" \"$pathtomingw\\$archlib\\lib\")

or am I missing something deeper? (very possible)

Hi Mark,

the trouble with $Config{libpth} is IMHO Windows specific (spaces are not
so common in directory names on UNIX systems) and happens for example in
this scenario​:
- you have perl in C​:\Program Files\Perl
- you have compiler in C​:\Program Files\Mingw-w64

After standard mingw build of perl you end up with​:
$Config{libpth}='C​:\Program Files\Mingw-w64\lib C​:\Program
Files\Mingw-w64\x64_86-w64-mingw32\lib'

The think is that many CPAN authors (+ maybe also EU​::MM, M​::B, M​::I) use
something like this​:
my @​libdirs = split / /, $Config{libpth};
# look for libfile in all members of @​libdirs

As you can see setting
$Config{libpth}='"C​:\Program Files\Mingw-w64\lib" "C​:\Program
Files\Mingw-w64\x64_86-w64-mingw32\lib"'
does not help much (not mentioning that " quoting is not portable to UNIX
platforms).

My suggestion was to use a separator (e.g. $Config{path_sep}) instead of
space or to introduce a new Config variable friendly to spaces in dirnames
(I am not sure if it is possible to create a Config variable that is not a
string but ARRAY reference).

--
kmx

From @markdootson

On 11/05/2011 08​:46, kmx wrote​:

Hi Mark,

the trouble with $Config{libpth} is IMHO Windows specific (spaces are not
so common in directory names on UNIX systems) and happens for example in
this scenario​:
- you have perl in C​:\Program Files\Perl
- you have compiler in C​:\Program Files\Mingw-w64

After standard mingw build of perl you end up with​:
$Config{libpth}='C​:\Program Files\Mingw-w64\lib C​:\Program
Files\Mingw-w64\x64_86-w64-mingw32\lib'

The think is that many CPAN authors (+ maybe also EU​::MM, M​::B, M​::I) use
something like this​:
my @​libdirs = split / /, $Config{libpth};
# look for libfile in all members of @​libdirs

As you can see setting
$Config{libpth}='"C​:\Program Files\Mingw-w64\lib" "C​:\Program
Files\Mingw-w64\x64_86-w64-mingw32\lib"'
does not help much (not mentioning that " quoting is not portable to UNIX
platforms).

My suggestion was to use a separator (e.g. $Config{path_sep}) instead of
space or to introduce a new Config variable friendly to spaces in dirnames
(I am not sure if it is possible to create a Config variable that is not a
string but ARRAY reference).

Hi,

I see your point. I'm only currently familiar with Linux/Windows/MacOSX.
Of those, it is only Linux where spaces in path names are uncommon and
quoting of paths doesn't work for the underlying OS. On MacOSX you
really need to account for spaces in path names and quote appropriately
in a manner similar to Windows.

Given that an unknown number of CPAN modules incorrectly rely on 'no
spaces in path names' for all sorts of uses, it does seem that the
simplest general solution is to insist on Perl installation to a path
with no spaces. Accommodating paths with spaces properly seems rather a
lot of work with little chance of getting a fully working solution
whatever approach you take. It is not a Windows only issue.

F.Y.I. As far as I'm aware, EU​::MM and M​::B seem to work with quoted
paths in $Config{libpth} on operating systems where you need to quote
paths with spaces in them (well, the two I've tried)

On the other hand ....

For Windows alone it would be nice to be able to install to 'Program
Files' for all sorts of reasons - so if you can come up with a way that
makes that workable, very sincere good luck with it.

Regards

Mark