Re: [FYI] {master} maint: assume 'test -x' is portable

[Stefano Lattarini]

Hi Eric, thanks for the quick feedback!

On 02/24/2012 12:25 AM, Eric Blake wrote:
> On 02/23/2012 04:10 PM, Stefano Lattarini wrote:
>> On 02/23/2012 11:49 PM, Harlan Stenn wrote:
>>> Eric wrote:
>>>> The autoconf manual still recommends:
>>>>
>>>> Do not use @samp{test -x}, because 4.3BSD does not
>>>> have it.
>>>>
>>>> Is this still an issue?  Or should we be updating the autoconf manual?
>>>
>>> I remember this biting me within the last ~4 years' time.
>>>
>>> I don't know if it's still an issue or not, though, as we might have
>>> places in our codebase where 'test -x' may have crept back in since
>>> then.
>>>
>>> If there is an easy way to test for it, I'd rather there was something
>>> like an AC_SANITY macro that would test for these ancient cases and
>>> squawk if the running system botched them.
> 
> Using the M4sh language of autoconf already has _AS_DETECT_BETTER_SHELL;
> we've used it for sanity probes in the past, and doing a sanity probe
> for a working 'test -x' and 'rm -f' now would be reasonable.
> 
Still, this is not 100% correct, as, e.g., a probe on 'rm' does not truly
pertain to a macro that, judging from its name, should check the features
of the shell.  Of course, taking this "route of least resistance" might be
good enough for the moment, so I'm not opposing your idea; but I believe
that a *public* AC_SANITY macro is the way to go in the long term.

> Question - should this still be advisory for autoconf 2.69 (probe, and
> loudly complain about failures of the probe, but use the fallback
> throughout the rest of the script) or mandatory (probe, and outright
> refuse to continue if the system doesn't meet the bare minimums, so we
> can simplify the rest of the script).
> 
> For 'test -x', that's usually a shell builtin; so we can require it of
> the shell.  For 'rm -f', that's a separate executable, so I'm leaning
> more towards a probe, and see what feedback we get, while still using
> the workarounds for now.
>
Sounds good to me...  but what is the "rm -f" workaround you are referring
to exactly? (and sorry if this is a dumb question).

>>>
>> .. I was preparing a patch about this already, that also
>> took care of removing the workaround for missing "test -x"
>> in M4SH.
> 
> You took care of part of it,...
> 
> 
>> +# This used to check whether `test -x' worked.  Today, this should be
>> +# the case on all non-museum systems, so just assume it works.
>> +# FIXME: this macro should probably be removed in a future refactoring.
>>  m4_defun([_AS_TEST_PREPARE],
>> -[if test -x / >/dev/null 2>&1; then
>> -  as_test_x='test -x'
>> -else
>> -  if ls -dL / >/dev/null 2>&1; then
>> -    as_ls_L_option=L
>> -  else
>> -    as_ls_L_option=
>> -  fi
>> -  as_test_x='
>> -    eval sh -c '\''
>> -      if test -d "$[]1"; then
>> -    test -d "$[]1/.";
>> -      else
>> -    case $[]1 in @%:@(
>> -    -*)set "./$[]1";;
>> -    esac;
>> -    case `ls -ld'$as_ls_L_option' "$[]1" 2>/dev/null` in @%:@((
>> -    ???[[sx]]*):;;*)false;;esac;fi
>> -    '\'' sh
>> -  '
>> -fi
>> +[as_test_x='test -x'
>>  dnl as_executable_p is present for backward compatibility with Libtool
>>  dnl 1.5.22, but it should go away at some point.
>>  as_executable_p=$as_test_x
> 
> We still have to set as_test_x for libtool; but I'm thinking we should
> go one step further, and rewrite AS_TEST_X to just blindly call 'test
> -x' rather than '$as_test_x', if we go with the minimum shell requirement.
> 
That's fine by me; I just took the "path of least modification" out of
laziness :-)  Do you want me to tweak and re-submit my patch, or will
you take care of it?

Thanks,
  Stefano