Mail Archives: djgpp-workers/2001/02/07/14:11:09
> Date: Wed, 07 Feb 2001 18:42:37 +0200
> From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> To: ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De
> Cc: djgpp-workers AT delorie DOT com
> Subject: Re: gettext pretest available
> Reply-to: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
> > For a reason I have still not fully understood, libiconv.a
> > likes to read and write always in text mode.
>
> Does that mean that `recode' now reads and writes files in text mode?
> If so, that's a terrible bug: a utility such as `recode' which
> converts arbitrary-encoded files should never use text-mode I/O,
> because of lone CR characters, the ^Z nuisance, and the need to be
> able to produce Unix-style EOLs when a suitable surface was requested.
>
> I thought libiconv.a was only used for converting characters, not for
> I/O. What am I missing?
Please note that this is really *preliminar*:
Yes, it seems to be that recode, at least, *writes*
the files in text mode. The testsuit invokes diff -u
and compares a "standard" file with the output file
created by recode. The only difference between the two files
is CRLF and NL. The recode output is ok but with the wrong EOL sequence.
The "standard" file is created by the testsuit script using
echo -n so it has the UNIX-style EOL.
Once again, all this is preliminar. I have stopped the recode port
due to the gettext and libiconv issue.
I will return to this as soon as possible.
Regards,
Guerrero, Juan Manuel
- Raw text -