On Mon, Nov 10, 2014, Ole Tange wrote:
> On Thu, Nov 6, 2014 at 1:54 AM, <edward.j.sa...@nasa.gov> wrote:
>> Whenever I run any parallel command (including "parallel --version"!), it
>> creates 61 files numbered 1 though 61 in the current working directory.
>> Most of these files have zero length, but file 1 and/or 2 sometimes
>> contain output from the parallelized commands.
[...]
> That is clearly a bug.
>
> It is happens in the function save_stdin_stdout_stderr(), which was
> introduced in version 20130630.
>
> So now we need to figure out why it happens on your system but not mine.
> We are running the same perl code, so that is not it. It is instead due
> to something in your environment.
It appears to be the version of Perl (5.8.0) parallel was trying to use on my
system. When I force parallel to use Perl 5.10.1, the bug is not present. I'm
satisfied with that solution. I don't expect 11-year-old Perl installations
to be supported. However, for the record, here's some info on the Perl
installation for which parallel appears to be broken:
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-27.7.xsmp, archname=i686-linux-64int-ld
uname='linux xyzzy 2.4.18-27.7.xsmp #1 smp fri mar 14 05:09:09 est 2003
i686 unknown '
config_args='-Uinstallusrbinperl -Dprefix=/usr/contrib/linux -Dcc=cc'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=define
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/sybase/OCS/include
-I/usr/contrib/linux/include -I/usr1/local/lib -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
Thanks,
Ed
