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

RE: runperl() exit oddity

Thread Previous | Thread Next
Steve Hay
August 7, 2013 17:29
RE: runperl() exit oddity
Message ID:
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
with the command line parsing code on VMS and Win32 too."

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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About