Skip Menu |

This queue is for tickets about the Test-Harness CPAN distribution.

Report information
The Basics
Id: 76111
Status: open
Priority: 0/
Queue: Test-Harness

People
Owner: Nobody in particular
Requestors: danboo [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.23
Fixed in: (no value)



Subject: prove --exec '' $test drops $test if ./$test dir exists
When calling prove as: prove --exec '' @tests prove drops tests that happen to also be names of sub-directories of the current working directory. I assume that this is interaction with the normal processing of *.t files in named directories. But it seems that if I've specified --exec '' (compiled tests) that searching directories should be disabled for *.t files should be disabled. In this example, my expectation is for the second call of prove to return "potato", just as the first call did prior to the existence of ./potato/. ~ > cat bin/potato #!/bin/sh echo "ok 1" echo "1..1" ~ > PATH=./bin:$PATH prove --dry --exec '' potato potato ~ > PATH=./bin:$PATH prove --dry --exec '' potato ~ > mkdir potato ~ > PATH=./bin:$PATH prove --dry --exec '' potato ~ > I could see it argued that the caller may have compiled *.t files, so searching named directories might break existing usage. If so, could there be an option to disable directory searching? Thanks! - danboo
My demo script included an extra line. It should read: ~ > cat bin/potato #!/bin/sh echo "ok 1" echo "1..1" ~ > PATH=./bin:$PATH prove --dry --exec '' potato potato ~ > mkdir potato ~ > PATH=./bin:$PATH prove --dry --exec '' potato ~ >
Subject: Re: [rt.cpan.org #76111] prove --exec '' $test drops $test if ./$test dir exists
Date: Thu, 29 Mar 2012 00:58:14 +0100
To: bug-Test-Harness [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Why is prove looking for tests in PATH? I think that's a bug or a serious misfeature.
On Wed Mar 28 19:58:32 2012, schwern@pobox.com wrote: Show quoted text
> Why is prove looking for tests in PATH? I think that's a bug or a
serious Show quoted text
> misfeature.
Is prove really searching PATH? I understood --exec '' to mean "there is no interpreter, just execute the tests via system()". It is also worth noting that this isn't just an issue with --exec ''. Even if I specify --exec 'bash -c' as my interpreter, prove still prefers the directory with no .t files over my executable. Perhaps the solution here is that I just provide full paths to my executables rather than depending on the DWIMmery of prove. Though it would be nice to have a way to say "my list of tests are things that output tap when passed to system() and they don't need interpreters or globbing".
Subject: Re: [rt.cpan.org #76111] prove --exec '' $test drops $test if ./$test dir exists
Date: Tue, 03 Apr 2012 13:27:23 -0400
To: bug-Test-Harness [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
The mix up here is that prove should never be looking in PATH. That bug is complicating the otherwise straightforward logic to run a file or a directory full of files. --exec or not, prove should never be looking in PATH. The arguments to prove should always be either a file to be executed or a directory to be searched, never an item to look for in PATH. There's no utility in it searching PATH. As the person running the tests, you can simply specify the full path to the executable. prove --exec '' bin/whatever If prove searches PATH it could run all sorts of unintended code. A simple typo of "halt.t" to "halt" could cause a computer to shut down. I grepped the code for any instances of PATH and found none. This must be some mistake in how the process is being executed, it uses open3. It must be invoking a shell. The code is in lib/TAP/Parser/Iterator/Process.pm and should be fixed. I don't have any leads on how to do that, it might be inherent in IPC::Open3. Meanwhile you can guard against this bug by specifying your executables with a leading ./ prove --exec '' ./bin/potato -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, "Order of the Stick" http://www.giantitp.com/comics/oots0107.html