[haiku-development] Re: cdrecord 2.01.01a63 results burning haiku-alpha cd
- From: Henri Vettenranta <henri.vettenranta@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 6 Sep 2009 20:32:18 +0300
On Friday 04 September 2009 21:57:30 scott mc wrote:
> 2009/9/4 Jonas Sundström <jonas@xxxxxxxxxxx>:
> > scott mc <scottmc2@xxxxxxxxx> wrote:
> > ...
> >
> >> ~/Desktop> cdrecord -version
> >> Cdrecord-ProDVD-ProBD-Clone 2.01.01a63 (i586-pc-haiku)
> >> Copyright (C) 1995-2009 Jg Schilling
> >
> > So that's where "Jg" came from!
> >
> > Might be a character encoding issue.
Looks like an ISO-8859-1-coded string that is tried to be interpreted as
UTF-8. Although I'd consider Terminal not showing the r still a bug, as
according to the UTF-8 standard, any byte with the most significant bit
unset means the same Unicode character as the same byte interpreted as
plain ASCII.
> It appears that is the case, I think this is the right section of
> code:
>
> if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
> printf("Cdrecord%s%s%s %s (%s-%s-%s) Copyright (C) 1995-2009
> Jörg
> Schilling\n",
Did you check what encoding the text editor used to open the file? Most
text editors try to automatically guess the encoding, and it seems in
this case it got it right.
Saving the source file as UTF-8 should fix the problem for Haiku (unless
the user has manually changed the encoding in his terminal), but the
real solution would be to either give up non-ascii characters, or use
libiconv to convert the string from a known encoding to the encoding
specified by the user's locale at run time. Of course, this requires that
the locale environment variables are set correctly, which I'm not sure
Haiku does by default.
--
Henri Vettenranta
HeTo
Other related posts:
