Jim Meyering wrote:
> Jim Meyering wrote:
> ...
>>> execve("/root/bin/no_such", ["no_such"], [/* 57 vars */]) = -1 EACCES
>>> (Permission denied)
>> ...
>>> /root/bin/ directory is not created in koji buildroot (it is not created by
>>> default at all) - so that might be the difference.
>> Thanks! The problem is that your PATH contains a
>> directory that disallows search access:
>>
>> $ (mkdir d && chmod u-x d && export PATH=d:$PATH; env no-such )
>> env: no-such: Permission denied
>> [Exit 126]
>>
>> in that case, execve fails with permission denied.
>>
>> I've just confirmed that Solaris 10's env command also
>> exits with status 126 in this case.
>>
>> I think the best way to fix this problem is to add a new predicate
>> that skips the test when PATH contains an unsearchable directory.
>>
>> Or better still: just rewrite PATH to exclude any such directory.
>
> Here's a patch to do just that:
>
> Note that while I'm using "local" here, it's not the first use.
> There's at least one existing use in require_proc_pid_status_.
>
> Technically using "local" is not good from a portability standpoint, but it
> seems better in the long run than continually obfuscating local variable
> names with trailing underscores. People with a losing shell can simply
> skip the tests or first install a modern shell.
>
>>From ab6b27eba720c04da91f5300121a6fe06d1fa9b4 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyer...@redhat.com>
> Date: Mon, 23 Nov 2009 17:35:20 +0100
> Subject: [PATCH] tests: avoid test failures when PATH contains an
> unsearchable directory
>
> * tests/test-lib.sh (sanitize_path_): New function.
> Always call it.
> ---
> tests/test-lib.sh | 28 +++++++++++++++++++++++++++-
> 1 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/tests/test-lib.sh b/tests/test-lib.sh
> index 456a30a..06087ea 100644
> --- a/tests/test-lib.sh
> +++ b/tests/test-lib.sh
> @@ -23,6 +23,31 @@ if test $? != 11; then
> Exit 77
> fi
>
> +# Having an unsearchable directory in PATH causes execve to fail with EACCES
> +# when applied to an unresolvable program name, contrary to the desired
> ENOENT.
> +# Avoid the problem by rewriting PATH to exclude unsearchable directories.
> +sanitize_path_()
> +{
> + local saved_IFS=$IFS
> + IFS=:
> + set - $PATH
> + IFS=$saved_IFS
> +
> + local d d1
> + local colon=
> + local new_path=
> + for d in "$@"; do
> + test -z "$d" && d1=. || d1=$d
> + if ls -d "$d1/." > /dev/null 2>&1; then
> + new_path="$new_path$colon$d"
> + colon=':'
> + fi
> + done
> +
> + PATH=$new_path
> + export PATH
> +}
> +
Looks good.
Would it be worth also warning here about components
of the path that are o+w, as that will cause test failures.
I had an untested off the cuff script for that here:
http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00247.html
cheers,
Pádraig.
