[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libevent: ChangeLog libevent-1.3e.ebuild

[Steve Long]

Steve Long wrote:
> No, that's about the size of it-- if you you'd like to tie it to ASCII,
> irrespective of locale, that's fair enough.
>
I had a feeling this statement was incorrect (what zlin said about a-z) so I
asked dalias in #bash who is knowledgeable about locale stuff:

<igli> dalias; have a q re: l10n. if we want to restrict allowed chars to
ASCII (for config) without affecting user's LC_CTYPE, what's the best way?
<dalias> igli, where do you want to restrict chars?
<igli> example i've seen is in checking a var
<dalias> checking a var to make sure it's all ascii?
<igli> yeah
<igli> [A-Za-z] isn't locale-safe is it?
<dalias> match it to a regex
<igli> hmm ok
<dalias> it's safe if LC_COLLATE=C
<igli>  ah thanks :D
<dalias> alternatively
<dalias> the most safe way is just to write all chars explicitly
<dalias> [ABCDEF...xyz]
<igli> hehe
<igli> ok nice one, i'll pass it on.
<dalias> anyway posix guarantees that the collation order in C locale is
ascii order
<dalias> even if the host's character encoding is something idiotic like
ebcdic

The odd bit (for me) is that [A-Za-z] is affected by LC_COLLATE not
LC_CTYPE, which makes sense if you think of it as a comparison. [[:class:]]
is ofc CTYPE.

So setting LC_COLLATE=C would appear to make sense, as long as you are never
dealing with user filenames, but only the portage tree (which seems a bit
yuck). A better general implementation might be a function that checks
against the explicit list, since that would have no implications for file
handling:

isAlphaASCII() {
for i; do
[[ $i = *[^ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzxyz]* ]] \
        && return 1
done
return 0
}

I /guess/ in sh the test line would be:
case "$i" in *[!ABC..xyz]* ) return 1;; esac


-- 
gentoo-dev@g.o mailing list