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

Re: test.pl runperl() exit oddity

Thread Previous | Thread Next
From:
George Greer
Date:
August 7, 2013 18:06
Subject:
Re: test.pl runperl() exit oddity
Message ID:
alpine.LFD.2.03.1308071404070.5243@m-l.org
On Wed, 7 Aug 2013, Nicholas Clark wrote:

> 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)

Appears so:

perl <nul.txt -e1 & echo %ERRORLEVEL%
0

> 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?

Special-cased in win32/win32.c:

     if (stricmp(filename, "/dev/null")==0)
         filename = "NUL";

> 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.

That I can't check at $WORK.

-- 
George Greer

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