Re: Supporting Macintosh FinderInfo/Resource Fork in Linux NWFS 2.0

Riley Williams (rhw@MemAlpha.CX)
Mon, 13 Dec 1999 23:04:54 +0000 (GMT)


Hi Jeff.

> You just verified that bash is striping the 8th bit. These codes
> are the box drawing symbols for ASCII -- that's what they output
> for you -- with the top bit striped. No offense, but why is bash
> so f_cking busted that it cannot even output ascii characters
> above 127?

There's one slight problem with your claim - NONE of the characters
listed have codes below 128. Check it out if you don't believe me!

> IMO this is f_cking busted and totally brain-dead. PC's have
> been supporting ASCII since 1980, so it's inexcusable that our
> shell programs are so archiac and limited in function.

Note that ASCII only defines codes 0 through 127, and there has NEVER
been a standard definition for codes 128 through 255, even on the IBM
PC itself. Check for yourself and you will find at least the following
different sets of definitions for that range:

1. IBM Character Set #1

2. IBM Character Set #2 (aka "PC Character Set").

3. Epson FX-80 Character Set.

4. MS-DOS Codepage 437 (aka "US codepage").

5. MS-DOS Codepage 850 (aka "International codepage").

All of the above are identical for codes 0 through 127, but differ
wildly from each other for codes 128 to 255, and ALL of the above
could be used with MS-DOS 2.11 onwards.

You can also list the recent additions of the Win9x character set
(different from ALL of the above), and of Unicode as well.

> Live and Learn .....

Very true.

>> I just used cut-and-paste to transfer that code into a text file
>> called x.c and then compiled it with `gcc -Wall -o x x.c` where
>> it compiled without any errors or warnings. Since I also run
>> under bash, I then ran the resultant program and saw as output a
>> column with the following in square brackets on each line,
>> described using standard ASCII rather than the actual
>> characters:

>> E acute
>> >>
>> E grave
>> 1/4
>> I grave
>> Superscript 1
>> Underlined superscript O
>> I acute
>> []
>> []

>> The last two had nothing inside them...

>> For reference, here's the result of `./x > xx` and telling
>> pine to insert xx in this message:

>> ===8<=== CUT ===>8===

>> [É]
>> [»]
>> [È]
>> [¼]
>> [Ì]
>> [¹]
>> [º]
>> [Í]
>> []
>> []

>> ===8<=== CUT ===>8===

>> The last two show up slightly differently here than they
>> did on the screen though...

Best wishes from Riley.

* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/