[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Command line too long" error when PATH is unset
From: |
Ole Tange |
Subject: |
Re: "Command line too long" error when PATH is unset |
Date: |
Sat, 27 Jan 2024 09:10:40 +0100 |
On Thu, Jan 25, 2024 at 2:52 PM Felix Abecassis
<felix.abecassis@gmail.com> wrote:
> Using GNU Parallel 20221122.
>
> In a bash script, I ended up calling something equivalent to the command
> below and it yielded a confusing error message:
>
> $ env -u PATH -u HOME parallel -k echo ::: A B C
> parallel: Warning: $HOME not set. Using /tmp.
> parallel: Error: Command line too long (6 >= -1338) at input 0: A
Yup. I never anticipated that echo would not be in your path. Next
release will fail with:
parallel: Error: echo must be in $PATH
> After looking at the source code, it looks like there might be two different
> things at play here.
> First of all, the fact that this statement yields a negative value for small
> values of "minimal_command_line_length":
> https://git.savannah.gnu.org/cgit/parallel.git/tree/src/parallel#n4912
>
> And second, the fact that if PATH is unset, it won't find the "echo" binary
> here: https://git.savannah.gnu.org/cgit/parallel.git/tree/src/parallel#n13714
> And thus instead of measuring the maximum command-line size, it seems it is
> measuring the maximum filename size? As hinted by what strace shows:
> [pid 372756] newfstatat(AT_FDCWD,
> "ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc",
> 0x7ffcd0c03a10, 0) = -1 ENAMETOOLONG (File name too long)
echo is used to figure out the longest command line available. It is
then cached in a file. This is used if you use -X to put in more
arguments than fit on a line.
We also need to know the maximal length of a file name. This is used
for --results.
So: Yes, two different unrelated things. The root cause is the missing
echo in $PATH.
/Ole