Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Test::Harness not working on my machine

by John M. Dlugosz (Monsignor)
on Jan 13, 2003 at 04:29 UTC ( [id://226393]=perlquestion: print w/replies, xml ) Need Help??

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

My first attempt to use the module: 
[prompt]perl -MTest::Harness -e"runtests 'test1.perl'"
test1.per...........'C:\Program' is not recognized as an internal or e
+xternal command,
operable program or batch file.
test1.per...........dubious
        Test returned status 1 (wstat 256, 0x100)
FAILED--1 test script could be run, alas--no output ever seen

[download]
According to the docs, "Test::Harness uses $^X to determine the perl binary to run the tests with." Meanwhile, it appears to simply concatenate it with the arguments and system() that string (or otherwise split on whitespace itself), because it things that the path up to the first space is the whole interpreter name!

Why do Perl tools have such problems with spaces? Haven't spaces (as well as control chars, and really anything except a slash) been legal on UNIX systems since the dawn of time?

In my own script, I reciently used $^X to launch another perl script and used the list form of system() with no problems. Perl knew that the first one was the program name, and how to quote or escape the argument strings properly on this platform.

So what's Test::Harness' problem? A quick search of the code shows: 

    my $cmd = ($ENV{'HARNESS_COMPILE_TEST'})
        ? "./perl -I../lib ../utils/perlcc $test "
          . "-r 2>> ./compilelog |" 
        : "$^X $s $test|";
    $cmd = "MCR $cmd" if $^O eq 'VMS';
    $fh->open($cmd) or print "can't run $test. $!\n";

[download]
or, to condense that, it turns into 
open FH, "$^X $scriptname|"

[download]
The pipe-out form of open takes a single string, as on a command prompt shell, rather than multiple arguments. Perhaps the new list form of open in Perl 5.8 is to provide exactly this? Anyway, the script has to take charge of knowing how to quote/escape whatever all the contents of the command to run.

That is fraught with system-specific details, so there should be something like File::Spec to hide that. Is there (yet)?

Second, this program makes no attempt to even try! Not only does it fall flat if the Perl path has spaces in it (on any platform), but the scriptname has the same problem. And it's not just spaces—any special characters used by the shell will mess it up, since they are not escaped.

I find it amusing that Test::Harness is not itself tested too see how it likes a standard Windows installation (typically C:\Program Files\... and ...\My Documents\...).

A quick edit to Test::Harness.pm involving 

my $interp_name= $^O eq 'MSWin32' ? Win32::GetShortPathName($^X) : $^X
+;

[download]
and it gets past that problem. Not as robust as it could be, though, since it doesn't handle Unicode names.

—John

Replies are listed 'Best First'.
Re: Test::Harness not working on my machine
by PodMaster (Abbot) on Jan 13, 2003 at 04:59 UTC
    Which version of Test::Harness?

    I haven't installed perl under "C:\Program Files" in over 2 years, but I recall this issue being resolved for a while now.

    Get the latest Test::Harness, and report back please.

    update: Holy schnikes man!!!! 1.1604 is quite ancient (that's the version that shipped). The latest is 2.26. Get it now ;D!

    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
      Get the latest Test::Harness, and report back please.

      Version 2.26 has the same problem.

      It's much more complex and split across multiple files now, but after some digging, I find: 

      open(FILE, "$cmd $switches $file|")

      [download]
      I modified line 273 of Test::Harness::Straps.pm to read 
          my $cmd = $self->{_is_vms} ? "MCR $^X" : ( $^O eq 'MSWin32' ? Win3
+2::GetShortPathName($^X) : $^X);

      [download]
      to add a case for Windows. Now it works again.

      —John

[reply]
[d/l]
[select]

        If you've not done so already, drop a bug-report and/or a failing test and patch to schwern (e-mail would probably be best - he doesn't seem to be a perlmonks regular :-)

        In my experience he appreciates patches!

[reply]
      After I read your post, I started downloading the last Perl 5.6.1 issued by ActiveState. It was taking its sweet time...

      Looks like the file date of the new one is September 2001, $VERSION = "1.1604";. It has the same use of the variables posted earlier.

      Well, to get 2.26... Hmm,

      "None of the range-specifier values in the Range request-header field overlap the current extent of the selected resource. > Apache/2.0.43 Server at search.cpan.org Port 80
      Download from CPAN.org instead,

      Well, it's own "nmake test" for Test::Harness gives me a whole bunch of t\callback.........'C:\Program' is not recognized as an internal or external command,, which sure looks like the same issue.

      Back to my directory, same problem: it cuts off the Perl interpreter name at the first space.

      —John

[reply]
[d/l]
[select]
      It's the one that came with ActiveState build 630, shipped Oct 31 2001.

[reply]
Re: Test::Harness not working on my machine
by schwern (Scribe) on Jan 14, 2003 at 00:24 UTC
    Using Win32::GetShortPathName() is a band-aid solution, but since this problem only seems to come up rarely and then only on Windows it should hold. I'd rather either do the shell escaping or use something that doesn't invoke a shell.

    Cross-platform shell escaping is a ROYAL PAIN IN THE ASS as I'm finding out in MakeMaker. This is an old, old, old problem which was simply left to rot because its so difficult to get right. ActiveState simply worked around the problem by moving the default install location from C:\Program Files\Perl to C:\Perl.

    Using open | doesn't please me but it seems to be the only cross-platform, backwards compatible thing to do. Can't use any whizz-bang 5.8.0 features, this thing has to work back to 5.4.0. 

    --

Michael G Schwern 	Just Another Stupid Consultant
schwern@pobox.com	http://www.pobox.com/~schwern/
[reply]
      I agree. My thought is to propose a function to add to the system-specific File::Spec module, but I'll post another node on that when I'm ready.

      re compatible: how about using the fancy Openxxx modules instead of the open| syntax? That is, you can use the list form of system() and arrange to have its standard output file handle piped to something you can read from.

      Hmm, the list form of system() already has platform-specific code for dealing with the arguments. It bypasses the shell and doesn't have to re-assemble them on UNIX I beleive, and on Windows it knows to put quotes around every individual argument before concatenating it together to form the command tail.

      Basically, using the no-shell form prevents the need for shell escapes, but there is still a portability issue of keeping the arguments separate (which already works fine).

      Also, what's wrong with using the list form of open in 5.8, and concatenating the list together for 5.6 or older? Just a line or two difference, easy to check the Perl version in an if() statement.

      —John

[reply]

        > re compatible: how about using the fancy Openxxx modules instead of the open| syntax?

        I remember having lots of trouble getting IPC::Open* working on some OS's. Currently I think that's whatever doesn't implement fork() (VMS immediately comes to mind). Most of the time it will work on Windows, but not if you use Borland's C compiler according to the tests.

        And that's just with the latest version of Perl. Don't want to know what it gets like as you go to older versions.

        > Hmm, the list form of system() already has platform-specific code for dealing with the arguments. It bypasses the shell and doesn't have to re-assemble them on UNIX I beleive, and on Windows it knows to put quotes around every individual argument before concatenating it together to form the command tail.

        system() doesn't help me, I can't capture the output reliably. :( Often system() will not respond to redirecting/tying *STDOUT and *STDERR inside Perl.

        > Also, what's wrong with using the list form of open in 5.8, and concatenating the list together for 5.6 or older? Just a line or two difference, easy to check the Perl version in an if() statement.

        Ok, send me a patch. Oh, and don't forget to try it out on Win98, Cygwin, VMS and Unix. 5.6.1 and 5.8.0 at least on each. 5.5.3 and 5.4.5 if you can. Thanks.

        Sorry to be a dick, but that's what's minimally involved in trying out new things with Mission Critical core modules like Test::Harness and MakeMaker. It Has To Work. Worse, It Has To Work Everywhere. And I'm usually the one that has to make sure it works everywhere. :( Its very time consuming. Yes I'm being crotchity.

        The latest Test::Harness alpha on CPAN has a work around that should work.

[reply]

Back to Seekers of Perl Wisdom

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?

www.com | www.net | www.org
Node Status?
node history
Node Type: perlquestion [id://226393]
Approved by shotgunefx
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? • Last hour • Other CB clients
Other Users?
Others sharing their wisdom with the Monastery: (4)
As of 2024-04-23 07:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found