Red Hat Bugzilla – Bug 142948
wc -m option unable to count the number of multibyte characters in a file
Last modified: 2014-03-25 20:51:56 EDT
Description of problem:
This bug is filed as it is one of the errors reported in the LI18nUX
test suite, part of the LSB conformance test.
It has been reported that when -m option is specified for the wc
utility, it cannot outputs the number of characters in the input file
even though the characters are multibyte characters.
I have stripped down the test suite to only the single test case. I
would really appreciate if you could have a look and let me know if
this is a glibc error or Test Case issue?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Down the attachment, wc1.tar.gz
3.view the result in the output file, tet_xres
Can't count number of characters.
Able to count these characters:
ãã® ãã¡ã¤ã« ã«ã¯ æ¥æ¬èªã å«ã¾ãã¦ ãã¾ãã in a file
Created attachment 108596 [details]
script with a single Test Case from LI18NUX Test for testing wc -m option
Here is my analysis of this for LSB 1.3. Note that this has nothing
to do with glibc, but with coreutils:
10|570 /tset/LI18NUX2K.L1/utils/wc/wc 00:21:33|TC Start, scenario ref 574-0
520|570 1 6181 1 1|* When -m option is specified, verify this utility outputs the number of characters in each input file even if the characters are multibyte characters.
520|570 1 6181 1 2|
520|570 1 6181 1 3|Can't count number of characters.
220|570 1 1 00:21:33|FAIL
520|570 2 6181 1 1|* When this utility writes to the standard output the number of words, this utility correctly recognizes the boundaries of words. The boundaries are shown as white-space characters constituted in current locale.
520|570 2 6181 1 2|
520|570 2 6181 1 3|Can't count number of words.
220|570 2 1 00:21:33|FAIL
LSB here expects that wc violates POSIX standard and prints say
POSIX requires "%d %d %d %s\n", <newlines>, <words>, <bytes>, <file>
format (with omitting the numbers that are not printed), see
The output file format pseudo- printf() string differs from the System V version of wc:
which produces possibly ambiguous and unparsable results for very large files, as it assumes no number shall exceed six
I'd say LSB testsuite should be changed to accept both at least.
This is fixed in LSB 2.0 already.
*** Bug 142949 has been marked as a duplicate of this bug. ***