Re: [PATCH 16/17] tests: more resilient about tainted absolute srcdir path

[Stefano Lattarini]

On 09/04/2012 05:21 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>> * tests/init.cfg (stty_reversible_init_): Quote '$abs_top_srcdir'
>> properly.
>> (fiemap_capable_): Quote '$abs_srcdir' properly.
>> (require_dirent_d_type_): Likewise.
>> ---
>>  init.cfg | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/init.cfg b/init.cfg
>> index 7edfd0f..13cac74 100644
>> --- a/init.cfg
>> +++ b/init.cfg
>> @@ -266,7 +266,7 @@ stty_reversible_init_()
>>  {
>>    # Pad start with one space for the first option to match in query 
>> function.
>>    stty_reversible_=' '$(perl -lne '/^ *{"(.*?)",.*\bREV\b/ and print $1' \
>> -    $abs_top_srcdir/src/stty.c | tr '\n' ' ')
>> +    "$abs_top_srcdir"/src/stty.c | tr '\n' ' ')
> ...
> 
> Thanks, but this c-set is unnecessary, since configure itself verifies
> the sanity of $srcdir and $abs_top_srcdir:
> 
>     { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether build 
> environment is sane" >&5
>     $as_echo_n "checking whether build environment is sane... " >&6; }
>     # Reject unsafe characters in $srcdir or the absolute working directory
>     # name.  Accept space and tab only in the latter.
>     am_lf='
>     '
>     case `pwd` in
>       *[\\\"\#\$\&\'\`$am_lf]*)
>         as_fn_error $? "unsafe absolute working directory name" "$LINENO" 5;;
>     esac
>     case $srcdir in
>       *[\\\"\#\$\&\'\`$am_lf\ \       ]*)
>         as_fn_error $? "unsafe srcdir value: '$srcdir'" "$LINENO" 5;;
>     esac
> 
> Did you find some case in which the absence of these changes
> would cause trouble?
>
In fact, no.  At first I thought I did (strange failure in "make distcheck"),
and thus I implemented this change; but then I noticed the failure was
actually due to another mess-up of mine (corrected before sending this
series, and whose details I've totally forget).  But I thought this change
could be useful anyway in making the tests more resilient.  Since you've
pointed out this is not the case, please just drop this patch.

> All of the others in that series look fine, modulo
> a few log-grammar nits, e.g., s/few/a few/
> 
> Thanks again,
> 
> Jim

Thanks,
  Stefano