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

Jeff V. Merkey (jmerkey@timpanogas.com)
Sun, 12 Dec 1999 20:21:42 -0700


Riley,

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? 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. Live and Learn .....

Jeff

Riley Williams wrote:
>
> Hi Jeff.
>
> >> The second issue is charset translation. I think you can simply
> >> use the code from fs/hfs/trans.c for this.
>
> > I am already handling the char set traslation for English names
> > in NWCREATE.C for MAC clients, so this is probably ok, but I'll
> > check this out to make sure I am doing it the same way hfs does.
>
> > Also, on a side note, I used the ACS_* characters for the
> > ncurses stuff, but for some reason, the display is still
> > striping the 8th bit during output.
>
> > Here's a code fragment that doesn't seem to output chars above
> > 127 on my bash shell (???). I'd love to know what's wrong here.
> > Any ideas?
>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <fcntl.h>
> > #include "termios.h"
> > #include "sys/ioctl.h"
> >
> > char buf[10] = { 201, 187, 200, 188, 204, 185, 186, 205, 0x1E, 0x1F };
> >
> > int main(int argc, char *argv[])
> > {
> > register int i;
> > struct termios term;
> >
> > ioctl(1, TCGETS, &term);
> > term.c_iflag &= ~ISTRIP;
> > term.c_cflag |= CS8;
> > ioctl(1, TCGETS, &term);
> >
> > for (i=0; i < 10; i++)
> > printf("[%c]\n", buf[i]);
> >
> > return 0;
> >
> > }
>
> 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/