http://qs1969.pair.com?node_id=123141

John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:

This is so frustrating... I want to get to the bottom of it once and for all.

Basically, the "normal" install procedure of using make maker never works.

Here is a specific example so you can see the errors I get. I started by downloading XML::Twig 3.00 from http://www.xmltwig.com/xmltwig/. The readme says:

INSTALLATION

    perl Makefile.PL
    make
    make test
    make install
So, here goes:
c:\temp\xml-twig-3.00\xml-twig-3.00]perl Makefile.PL Checking if your kit is complete... Looks good Have C:\Program Files\Languages\Perl\lib\Config.pm expected C:\PROGRA~ +1\Languages\Perl\lib\Config.pm Your perl and your Config.pm seem to have different ideas about the ar +chitecture they are running on. Perl thinks: [lib] Config says: [MSWin32-x86-multi-thread] This may or may not cause problems. Please check your installation of +perl if you have problems building this extension. Writing Makefile for XML::Twig
First, the PROGRA~1 is an alias for "Program Files". Perl was installed using the alias to avoid spaces in file names. So no problem here, except that it seems to ignore the effort.

Next step is more problematic:

c:\temp\xml-twig-3.00\xml-twig-3.00]make 4NT: Unknown command "make"
OK, so I try "nmake" instead, as is common lore.

It includes the line "cp Twig.pm blib\lib\XML\Twig.pm" in its output, which is disconcerting because "cp" is not a command. But there was no error or warning, so what's up?

Next step: nmake test.

kaboom!

Using C:/TEMP/XML-Twig-3.00/XML-Twig-3.00/blib t\is_field..........'C:\Program' is not recognized as an internal or e +xternal command, operable program or batch file.
It's written to assume (don't you love that word?) that nothing in the filename needs escaping. Which is odd because the standard location for programs has a space in it. Looking carefully, I think this just affects the running of the tests, not the meat of it. So onward...

nmake install fared better, using the PROGRA~1 alias. So using that when I installed Perl seems to have overcome a major hurdle, but it's still not complete.

It reacts favorably to perl -MXML::Twig now, so I suppose this is a success. But it didn't update the ActiveState documentation index. Isn't there a utility program somewhere to force the tree to be re-processed?

so where are we?

The ActiveState installer needs to automatically use the short-name alias. Meanwhile, all programs need to either fetch this "official" name, or properly escape out the name discovered by $^X other other means. Since $^X is documented to not necessarily be useful for this purpose, I wonder where these install scripts are getting their information from, and if that's the root of the problem. Isn't the right way to get the path to the executable to use the Config module? Doing it by other means is why it saw "Program Files\" in some places and "PROGRA~1" in others.

Second, shouldn't there be a portable way to escape out filenames for the current OS? We should use that function! (what is it?) Putting an argument in quotes is probably normal for the rest of the command line (but which kind of quotes?), but how to show the program name itself, when writing a batch file, make file, or other script, is something that needs to be abstracted.

—John