Bug 245040 - `man iconv` or `iconv --list` doesn't mention switch "ASCII//translit"
Summary: `man iconv` or `iconv --list` doesn't mention switch "ASCII//translit"
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: man-pages
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-20 17:43 UTC by Josef Kubin
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-07 12:57:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Josef Kubin 2007-06-20 17:43:54 UTC
Description of problem:
How to convert a Czech file full of diacritic signs into ASCII without mr. Google?
It is impossible without knowledge of the undocumented switch.

$ cat utf8.txt
áäâăąćčçďđéěëęíîĺľłńňóôöőŕřśšşťţúůüűýźžż
ÁÄÂĂĄĆČÇĎĐÉĚËĘÍÎĹĽŁŃŇÓÔÖŐŔŘŚŠŞŤŢÚŮÜŰÝŹŽŻ

$ iconv -f UTF8 -t ASCII utf8.txt
iconv: illegal input sequence at position 0

$ iconv -f UTF8 -t ASCII//translit utf8.txt 
aaaaacccd?eeeeiill?nnoooorrsssttuuuuyzzz
AAAAACCCD?EEEEIILL?NNOOOORRSSSTTUUUUYZZZ

Version-Release number of selected component (if applicable):
glibc-common-2.5-10.fc6

How reproducible:
always

Comment 1 Jakub Jelinek 2007-06-20 18:09:48 UTC
man-pages aren't part of glibc and iconv -l is really supposed to give you
list of the charsets, not supplement a manual page and tell you about all
possible modifiers.
//TRANSLIT and //IGNORE are documented at:
http://www.gnu.org/software/libiconv/documentation/libiconv/iconv_open.3.html
But it can be a name of a user provided shared library that implements
special translation as well.

Comment 2 Josef Kubin 2007-06-26 23:48:17 UTC
Yeah, glibc is completelly different thing :-) I simply issued the following
command:

$ rpm -qf /usr/bin/iconv
glibc-common-2.5-10.fc6

Maybe `iconv --list` should give a hint, because I can't imagine to integrate a
such marginal thing into "iconv" man page.

Comment 3 Josef Kubin 2007-07-09 17:33:21 UTC
The fix as an example to the man page seems to be good and painless solution ...
My proposal:


--- man 2007-07-09 19:29:29.000000000 +0200
+++ fix4man     2007-07-09 19:31:35.000000000 +0200
@@ -30,6 +30,13 @@
 
        Print progress information.
 
+EXAMPLES
+       Following examples convert from code set ISO88592 "input.txt" to UTF8
code set or ASCII and stores the result as "output.txt".
+
+       iconv -f ISO88592 -t UTF8 < input.txt > output.txt
+
+       iconv -f ISO88592 -t ASCII//TRANSLIT < input.txt > output.txt
+
 AUTHOR
        iconv is written by Ulrich Drepper as part of the GNU C Library.


Comment 4 Marcin Garski 2007-08-04 20:05:50 UTC
Iconv man page provided by man-pages doesn't mention //TRANSLIT, //IGNORE but
also -c and -s.

If you want I could provide new iconv man page heavily based on the one from
libiconv which will match latest iconv from glibc, are you interested?

Comment 5 Ivana Varekova 2007-08-07 12:57:05 UTC
Thanks Josef, the patch is applied in the last version of man-pages in fedora
(man-pages-2.63-3.fc8).
Thanks very much Marcin, it would be great if you contact Michael Kerrisk - he
is the man-pages upstream maintainer and he will be the best person who know the
recent status of man pages and who could use your work in the upstream version. 
If there is any problem with contacting Michael Kerrisk, write here a comment or
write me an e-mail. Thanks again.

Comment 6 Marcin Garski 2007-08-07 20:11:50 UTC
The problem is that iconv(1) I'm telling about, and which Josef's patch has been
included came from man-pages-extralocale.tar.bz2. iconv(1) man page in this
archive are from Debian's glibc package (BTW Debian glibc have newer version of
this man page).
iconv man page from man-pages is iconv(1p) (note the 'p'), but when user type
"man iconv" iconv(1) is selected. iconv(1p) isn't synced with glibc's iconv either.

I was about to contact man-pages upstream maintainer, but after checking this I
wrote in this bug about new iconv(1) matching latest iconv from glibc :)


Note You need to log in before you can comment on or make changes to this bug.