Console ASCII interpretation

[alexander]

On Mon May 16 05, Warner Losh wrote:
> 
> The ANSI character set standard doesn't talk at all about how
> characters are rendering.  Terminal emulation software renders the
> characters as they see fit.  NIL is *NOT* a NOP.

OK. You defentately have a point right there. Surely telling write(2)
to render 4 bytes, when you only want 2 bytes to be shown is not good
programming style.

On the other hand: When you're saying that NUL is != NOP then that's
OK. But what is == NOP. If there was a value that would do a NOP then
I could do that, but there isn't.

Frankly...when I enter an ascii value directly (ALT+3-digits) the
console behaves differently. Because when I enter ALT+000 it DOES
produce a NOP. That seems a bit random to me.

> 
> I guess what I'm trying to say is that if you output NUL, then you are
> telling the terminal emulation to do something.  Don't be surprised
> when it does do something :-).
> 
> The bottom line is that your code is wrong, and your understanding of
> NUL in this context is wrong and you need to fix both.
> 
> Warner

You're right. The code I'm using is wrong when it is being executed
under the console. However the fact that Eterm and xterm do what I
want to do with my app show that I'm not the only one who needs a
NOP ascii value. Both render the NUL ascii code as NOP. Since both
terms are much newer than the console this indicates that they
reflect the recent changes in software development much better.

Keeping code simply because of historic reasons doesn't seem  too obvious
to me. There are a lot if ways to let the user decide whether he
prefers historic code over new code. Hence all the COMPAT options
in the kernel.

But it's obvious, that it would be much easier if I change my code to
only display that many bytes as I really want to be displayed.

Thx for the help.