Re: cannot configure coreutils-9.4

[Timothy Sample]

An update:

Timothy Sample <samplet@ngyro.com> writes:

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:
>
>> { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $gt_cv_locale_fr" >&5
>> printf "%s\n" "$gt_cv_locale_fr" >&6; }
>>   LOCALE_FR=$gt_cv_locale_fr
>>   case $LOCALE_FR in #(
>>       '' | *[[:space:]\"\$\'*[]*)
>>       #'' | *[\"\$\'*[]*)
>>             { printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: invalid 
>> locale \"$LOCALE_FR\"; assuming \"none\"" >&5
>> printf "%s\n" "$as_me: WARNING: invalid locale \"$LOCALE_FR\"; assuming 
>> \"none\"" >&2;}
>>       LOCALE_FR=none;;
>>   esac
>
> Huh.  First of all, that pattern looks fishy to me.  (Technically it’s
> okay, and Gash should handle it, but it’s very odd to have the bare
> opening bracket at the end like that.)

Gash *can* handle that part.  It’s normal to do that to get “[” as part
of a bracket expression.  We even have a test for it!  :)

>Because of that, I wonder if the problem occurs earlier.  Looking at
>gnulib, the "[]" at the end is substituted in....  Either way, I will
>take a look and make it work.

This is also normal.  Due to M4 quoting, “@<:@” is how “[” is written.

It turns out Gash doesn’t like the character class (“[:space:]”).
(Judging by the commented line, you may have already figured that out!)
This is because Guile does not directly support locale dependent
character classes.  I guess using regular expressions would get us
there, since Guile uses the C library for that.  However, that’s a bit
of a kludge.  We could also ignore locales and use Unicode character
classes, but that runs a little roughshod over the semantics of the
shell.  Let me think about it.

In the meantime, how about replacing “[:space:]” in the configure script
with “"$IFS"”?  (Mind the quotes!)  From reading the Gnulib commit and
associated Emacs thread, it looks like that’s the intent anyway.


-- Tim