Re: [Rd] minor iconvlist() bug in r-devel

From: Deepayan Sarkar <deepayan_at_stat.wisc.edu>
Date: Wed 16 Mar 2005 - 17:25:27 GMT

On Wednesday 16 March 2005 10:57, Prof Brian Ripley wrote:
> On Wed, 16 Mar 2005, Deepayan Sarkar wrote:
> > On Wednesday 16 March 2005 10:11, Prof Brian Ripley wrote:
> >> That file is created by
> >>
> >> $(top_builddir)/library/$(pkg)/iconvlist: most
> >> @iconv -l > $@ 2> /dev/null || touch $@
> >>
> >> What version of iconv -l is that produces such a list? That in
> >> glibc 2.3.4 does not produce the header when redirected.
> >
> > I have version '2.3.2.ds1-20' on Debian testing. '--silent' doesn't
> > help.
>
> I found an old RH9 system that did the same thing.
>
> >> Your fix is not safe: iconv in libiconv produces items separated
> >> by space or newline. Looks like we will have to work harder to
> >> distinguish the two.
> >
> > Can anything with a lowercase letter be safely rejected? That would
> > bring the spurious names down to 2 (FROM and TO).
>
> No. I think what we can do is to look to see if most lines end in
> //, and if so assume glibc format.

Yes, that should be good enough. Actually, the matches intended by the glibc version seems to be those that look like "^.*/.*/$". In particular, there are names like

ISO-10646/UCS2/
ISO-10646/UCS4/
ISO-10646/UTF-8/
ISO-10646/UTF8/

which should end up as

ISO-10646/UCS2, ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8 but currently end up as

 [545] "ISO-10646/UCS2/"        "ISO-10646/UCS4/"
 [547] "ISO-10646/UTF-8/"       "ISO-10646/UTF8/"

The libiconv equivalents look like

ISO-10646-UCS-2
ISO-10646-UCS-4 which should be fine as they are.

Deepayan



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu Mar 17 04:29:00 2005

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:02 GMT