Subject: Re: tr A-Z a-z in locales other than C



On Tue, Jun 07, 2011 at 11:17:12PM +0200, Jilles Tjoelker wrote:
> In FreeBSD, upper case sorts before lower case, so cases can be
> distinguished this way but all letters may require two ranges. In most
> other operating systems the cases go together so a single range is
> sufficient, but cases cannot be distinguished. Making such things work
> on multiple operating systems requires careful testing.

Such thing can't work consistenly on multiple operating systems by
definition, because POSIX states "undefined" here. So the best we can is
to concentrace on our system. No program should relay on that until POSIX
define that somehow.

> > Moreover, having differently treated regex ranges in tr vs other places
> > you mention will produce additional chaos.
>
> I think this is already inconsistent because some programs do not enable
> locale or use different locale code.

I say the same, producing additional chaos is not bringing chaos from
nowhere.
AFAIK nobody use different locale code but often different regex
implemetation.

> > Back to the ports: it is not hard to run _any_ port's make or configure
> > with LANG=C directly by the ports Mk system to eliminate that problem.
>
> True, but some ports install scripts with problematic tr calls.

What count says, how many ports do that?

Summarizing I suggest to consider two models:
1) Developer/programer etc. tr coderange does good for it.
2) Working with national language docs/end user/ tr coderange does bad for
it.

Sacrificing model 2) for 1) is not the thing we need, if such ports number
is low. If such ports number is significant, we can consider additional
options like automatically search and replace such tr's through pkg-plist
(similar scanni...

ng we already do for security reasons).

--
http://ache.vniz.net/
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Privacy