All I am trying to do is get a CWorthy style interface up on Linux for
all the Netware NDS and NWFS Utils and such. On a standard PC, this is
pretty easy to do with NT, DOS, NetWare, and WIn95/98. I've got a
single source Lib that handles all of them for CWorthy -- For the DOS
version, it's direct screen writes, for NT the Console Text APIs, and
for Linux it's (n)curses, except Linux has the poorest look and feel of
the three because the default for these shells don't let you use all
ASCII charaters to make cool little boxes and such without a lot of work
and research into how shells work.
Again, the point that is missed is that for all you "unix hacker guru
types" having to do "set meta-on" an such in a /.inputrc file may not be
a big deal, but end user customers are lazy and don't want to do a weeks
worth of research just to get their displays to look like what they are
used to with NetWare, DOS, NT, Windows 95/98, etc. I know you guys
think I'm anal here or something, but I am trying to make this easy for
our folks who will buy a Caldera or RedHat commercial Linux and the
stuff just works without the user needing to do all this extra stuff to
get what they can get "free and easy" from Microsoft and Novell (like
simple text graphics support for utilities).
Jeff
Alan Curry wrote:
>
> Jeff V. Merkey writes the following:
> >You just verified that bash is striping the 8th bit. These codes are
>
> You are really showing your cluelessness here. First with the Jeopardy
> quotes. Then with your assumption that your shell is solely responsible for
> what shows up on your screen.
>
> What *you* just verified is that *your* terminal and/or your mailreader is
> not showing non-ASCII characters. I saw them just fine so I know they're
> passing through the mailing list.
>
> HERE ARE SOME FREE CLUES:
>
> 1. Your shell does not control your terminal! The shell just runs programs.
> It may provide your program with some well-known initial state, but after
> that your program is free to manipulate the terminal however it wants WITHOUT
> THE SHELL'S INVOLVEMENT.
>
> The problems you are experiencing exist between YOUR TERMINAL and YOUR
> PROGRAM. Your shell has zero responsibility. Now I want you to go to the
> blackboard and write "THE SHELL IS NOT RESPONSIBLE" 50 times.
>
> ...
>
> Ah good, you're back. Now that you understand that your shell is irrelevant,
> let's talk about some things that are relevant:
>
> 1. Your terminal type!
> 2. The value of your TERM environment variable
> 3. The contents of your termcap and terminfo entries
> 4. What the fuck you think this might have to do with the kernel and why you
> think you're too important to post your obvious unix-newbie questions on
> comp.unix.programmer or comp.os.linux.misc
>
> There are people who would try to help you if you wouldn't jump to incorrect
> conclusions based on principles that are so far off base we can't even figure
> out how you got there.
>
> >the box drawing symbols for ASCII -- that's what they output for you --
>
> Here's another free clue: ASCII is a 7-bit character set whose "line-drawing"
> characters are the hyphen, underscore, and pipe (and slash and backslash for
> diagonals!). The characters you are thinking of do not exist in plain ASCII.
> They only exist in various mutually-incompatible extensions, *one* of which
> is the old PC ROM character set.
-
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/