This is the mail archive of the
mailing list for the glibc project.
RE: Problems with message catalogues on Red Hat Linux 7 on Alpha
- To: "Wood, John (REO)" <woodjohn at compaq dot com>
- Subject: RE: Problems with message catalogues on Red Hat Linux 7 on Alpha
- From: Bruno Haible <haible at ilog dot fr>
- Date: Fri, 16 Mar 2001 15:53:09 +0100 (CET)
- Cc: libc-alpha at sources dot redhat dot com
- References: <69497A35EFE01E40877E250AB1AD61EA0919F7@reoexc03.emea.cpqcorp.net>
John Wood writes:
> In trying to produce a small example which demonstrated my
> problem with message catalogues I have fixed my problem.
> I was using the output from "mkcatdefs" on Tru64 UNIX as the
> input for gencat on Linux. The format of this file included
> lines like:
> $delset 1
> $set 1
> 1 "Message 1\n"
> 2 "Msg 2"
> 3 "Msg three"
> 4 "Message 4"
> where there is lots of white-space between the message number
> and the string in some of the lines.
> I noticed that catgets() worked for message 3 above, but not
> the others. Note how msg 3 has just a single space between
> the number and the string. For the other messages, catgets()
> just returned a string of white-space.
> The solution is to remove the extra white-space, so that all
> message lines are as per message 3.
> So I stand corrected: there is not a bug with message
> catalogues on Linux; it's just a bit sensitive to white-space.
The SUSV2 description of gencat says
"Note that the fields of a message text source line are separated
by a single blank character. Any other blank characters are
considered as being part of the subsequent field."
Thus the output from your "mkcatdefs" was not valid input for gencat
in general. (It might be valid on Tru64; that would be a vendor
extension or perhaps a bug.) Not a bug in glibc.