Re: Findutils failure due to reliance /bin/echo

[James Youngman]

On Wed, May 5, 2010 at 11:30 PM, James Youngman <address@hidden> wrote:
> [ CC += address@hidden ]
>
> On Wed, May 5, 2010 at 3:53 PM, Ludovic Courtès <address@hidden> wrote:
>> Hi James,
>>
>> James Youngman <address@hidden> writes:
>>
>>> On Wed, May 5, 2010 at 9:35 AM, Ludovic Courtès <address@hidden> wrote:
>>>> Hi James,
>>>>
>>>> Hydra Build Daemon <address@hidden> writes:
>>>>
>>>>> FAIL: l1, unexpected failure, child process exited abnormally, 
>>>>> /tmp/nix-build-iqdrm25mpg40iivc59hjmdjjay1rfifp-findutils-4.5.10-git.drv-0/findutils-4.5.10-git/xargs/testsuite/../xargs:
>>>>>  /bin/echo: No such file or directory
>>>>
>>>> This is due to the fact that there’s no /bin/echo in the build
>>>> environment (actually /bin on NixOS contains only /bin/sh).
>>>>
>>>> If you want to rely on ‘echo’ other than the shell’s built-in, you
>>>> should use AC_PATH_PROG([echo]) in ‘configure.ac’ or something similar.
>>>> (Though I can’t think of any reason why the shell built-in wouldn’t
>>>> work.)
>>>
>>> Well, the shell builtin can never work because you can't exec it.
>>> POSIX requires xargs to run echo, though:
>>>
>>> utility
>>>     The name of the utility to be invoked, found by search path using
>>> the PATH environment variable, described in the Base Definitions
>>> volume of IEEE Std 1003.1-2001, Chapter 8, Environment Variables. If
>>> utility is omitted, the default shall be the echo utility. If the
>>> utility operand names any of the special built-in utilities in Special
>>> Built-In Utilities , the results are undefined.
>>>
>>> So essentially, the echo binary is a runtime dependency for findutils.
>>
>> Understood, thanks for explaining.
>>
>> Still, ‘AC_PATH_PROG([ECHO], [echo])’ and then referring to @ECHO@
>> instead of /bin/echo in xargs.in.c would remove this path assumption.
>>
>> What do you think?
>
> The idea makes me very nervous indeed.   Implementing things that way
> would mean that the built xargs would fossilise the effect of whatever
> setting was in $PATH at the time xargs is built.   This could give
> rise to odd surprises (and differences from long-standing behaviour)
> for some people.  An alternative would be to use execvp on an
> unqualified program name and have the invoked version of echo be
> sensitive to the user's $PATH value.  Of course that will also
> potentially produce not-immediately-obvious inconsistencies of
> behaviour.
>
> As far as I can tell, there is no requirement in POSIX or the SVID
> which would require "echo" to live in a particular directory, and none
> which would require xargs to expect echo to live in /bin.
>
> However, I'm still very reluctant to change such a long-held property,
> and most certainly not without a great deal of advance warning.

Well, that was a year ago.... but it was less than an explicit
warning.   So, here is a more explicit warning:

xargs will change to invoke "echo" by default rather than "/bin/echo".
  This change will probably occur in the next development release.
It will also be included in the stable release series deriving from
that (meaning the change will be included in 4.6.0 but not in any
4.4.x release).

This will result in possibly-subtle behaviour changes for users whose
$PATH specifies a directory containing a different echo, before /bin.
In order to avoid an unexpected surprise, please just use an
explicitly-specified utility with xargs.  That is, use

xargs /bin/echo < foo

instead of

xargs < foo

Thanks,
James.