Correct me if I'm wrong, but OP said:

Turns out it was because the PATH didn't exist in the Jenkins environment.
Why would the open succeed to an unknown executable?

$ env LC_ALL=C PATH="" /usr/bin/perl -E'open my $fh, "-|", $_ and say 
+"success" or say $! for "ls", "/bin/ls"'
No such file or directory
success
[download]

The only path I see in the OP is that pointing to the file the executable is meant to process:

/opt/humana/svn/checkouts/rosalind-repo/prod/tmp/testfile.pdf
[download]

The executable name is provided unadorned; so either in the current working directory or to be located via the path environment variable.

But, as I've no knowledge of what the "Jenkins environment" is; it could be me misinterpreting the question.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

I was talking about prince. Since (as OP found out) Jenkins had cleared PATH environment variable, and (supposedly) there was no prince executable in the current directory (or the script was running on a UNIX-like system where executables are not run from current directory unless $PATH contains .), OP thought that open($fh, "|-", "prince ...") should have failed, but it didn't because there was a $Config{sh} between Perl and prince in the process tree.

It was the not finding "prince" that caused it to fail (pretty much what aitap said).

Intuitively, I would think the open should fail if the executable being piped to can't be found, but that wasn't the case.

I added a test for the print, and that appears to return true.

So, what I have is:

ok 3 - Opened pipe
ok 4 - Piped content to prince
not ok 5 - Closed pipe
[download]

I'm wondering if an assumption is made internally about piping to the executable until Perl receives a return value on closing?!?

I'm wondering if an assumption is made internally about piping to the executable until Perl receives a return value on closing?!?

Looking back at what you're sending down the pipe; it is way less than the typical 4kb buffer size; which means nothing will be sent until you try to close, at which point it will attempt to flush the buffer through and it is only at that point that the broken pipe will be discovered.

You could verify that conjecture by trying to print more data to the pipe:

       my $fh;
        ok( open($fh, "|-", "prince - 2>/dev/null $test_file"), "Open 
+$test_file for writing" );
        print( $fh 'x' x 1024 ) or die "Print failed at $_ with $!" fo
+r 1 .. 5;
        ok( close($fh), "Close $test_file");
[download]

My guess is that will fail at the 4th or 5th iteration with "Broken pipe".

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!