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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
