Re: autoconf test for `ls -t` doesn't account for envar QUOTING_STYLE

[Cathy Garrett]

On 10/24/18 12:37 AM, Nick Bowler wrote:
> On 10/23/18, Cathy Garrett <address@hidden> wrote:
>> I've found a bug in autoconf related to the ls command's environment
>> variable QUOTING_STYLE.
>>
>> By having QUOTING_STYLE=c in my environment, the following stanza fails.
>> The reason for the failure is in the code
> [...]
>>      set X `ls -Lt "$srcdir/configure" conftest.file 2> /dev/null`
> [...]
>> if test "$*" != "X $srcdir/configure conftest.file" \
>>         && test "$*" != "X conftest.file $srcdir/configure"; then
>>
>> My ls is not aliased, but because of my use of the envar QUOTING_STYLE,
>> it makes $* look like this:
>>
>> X "./configure" "conftest.file"
> Oh lovely, so GNU coreutils grew a portability wart in that having this
> variable in the environment breaks longstanding unix tradition on how
> "ls" should behave, and presumably this is also at odds with the POSIX
> standard...
>
> I guess the portability section of the Autoconf manual needs an update.
>
> I suspect m4sh should forcibly unset this variable during shell init,
> like it does with CDPATH.  Unfortunately, if setting it to the empty
> string is bad, there is no portable way to unset variables...  maybe
> that doesn't matter for any system running suitably new versions of
> GNU ls.  Alternately, one could do something like (untested) early in
> configure:
>
>   test ! ${QUOTING_STYLE+y} || QUOTING_STYLE=literal
>
> to work around setting it to the empty string...
>
> Cheers,
>   Nick

I agree. QUOTING_STYLE envar is a bad idea. Nothing wrong with
--quoting_style= cmdline arg. At least then, if shoehorned into an
alias, at least the autoconf error message would still be right. In the
interrim, just adding a blurb about "it might be an alias for ls or the
QUOTING_STYLE envar" would be ample, in my opinion.