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
