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." 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 D:\temp>
