[Rd] minor iconvlist() bug in r-devel
Deepayan Sarkar
deepayan at stat.wisc.edu
Wed Mar 16 18:25:27 CET 2005
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
More information about the R-devel
mailing list