develooper Front page | perl.perl5.porters | Postings from August 2013

Re: test.pl runperl() exit oddity

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
August 7, 2013 17:40
Subject:
Re: test.pl runperl() exit oddity
Message ID:
20130807174003.GZ3729@plum.flirble.org
On Wed, Aug 07, 2013 at 06:29:26PM +0100, Steve Hay wrote:
> Nicholas Clark wrote on 2013-08-07:
> > It turns out that this causes fun on AIX with two tests, because on
> > AIX /bin/sh is actually ksh, and ksh does pipes differently (with one
> > less process). With sh, for the latter command line the sh process
> > forks two children, which use exec to start the two perl processes.
> > The parent shell process persists for the duration of the pipeline,
> > and the second perl process starts with no children. With ksh (and
> > zsh), the shell saves a process by forking a child for just the first
> > perl process, and execing itself to start the second. This means that
> > the second perl process starts with one child which it didn't create.
> > This breaks the tests assume that wait (or waitpid) will only return
> > information about processes started within the test. One can replicate
> this is on Linux:
> > 
> > $ sh -c 'pstree -p $$ | cat'
> > sh(13261)-+-cat(13263)
> >           `-pstree(13262)
> > $ ksh -c 'pstree -p $$ | cat'
> > cat(13349)---pstree(13350)
> > 
> > 
> > I thought about fixing the tests to make them immune to unexpected
> > extra child processes, but then realised that it was probably easier
> > to change the generated backtick command to be
> > 
> >     `./perl </dev/null -Ilib -e ...`
> > 
> 
> And the commit message for reads:
> " Fortuitously it seems that the string /dev/null is portable enough to
> work
> with the command line parsing code on VMS and Win32 too."

Yes, I asked on #win32 and didn't get a useful answer.
Thanks for spotting this.

> What command line parsing code are you talking about here? I'm not aware
> of /dev/null being valid on Windows in general; I've always used the
> device called nul instead:
> 
> D:\temp>perl </dev/null -e1
> The system cannot find the path specified.
> 
> D:\temp>perl <nul -e1

Does

    perl <nul.txt -e1

work too?

(ie it's still compatible with MS/DOS and earlier)


My assumption was based on what seem to be several regression tests
that opened /dev/null and aren't failing on Win32.


Starting with this in t/base/term.t:

open(try, "/dev/null") || open(try,"nla0:") || (die "Can't open /dev/null.");

also t/lib/warnings/pp_sys has

########
# pp_sys.c [pp_leavewrite]
use warnings 'io' ;
format STDOUT_TOP =
abc
.
format STDOUT =
def
ghi
.
$= = 1 ;
$- =1 ;
open STDOUT, ">".($^O eq 'VMS'? 'NL:' : '/dev/null') ;
write ;
no warnings 'io' ;
write ;
EXPECT
page overflow at - line 13.
########


and t/lib/warnings/sv contains


open F, ">".($^O eq 'VMS'? 'NL:' : '/dev/null') ;


Is it that /dev/null works from within perl, but not on the command line?


If so, the fix would seem to be to change the new code to

        $runperl = $runperl . ($is_mswin ? ' <nul' : ' </dev/null');

Does this make t/op/fork.t test 16 pass again on Win32?
That now seems to be failing, and I don't know why.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About