osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/09/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Fri, 8 Mar 85 Volume 4 : Issue 8
Today's Topics:
\e and terminfo
What ftell returns
----------------------------------------------------------------------
Date: Fri, 8 Mar 85 01:18:51 est
From: mark@cbosgd.ATT.UUCP (Mark Horton)
Subject: \e and terminfo
To: std-c@cbosgd.uucp
>On a related note, I can't think of any use of \e (escape) that should not
>be a primative found somewhere in termcap or terminfo. Perhaps I am
>missing something, but if I am not then what goes for \a also goes for
>\e. And those environments which do not have a termcap/terminfo facility?
>I would rather that *they* get one than we all get \a.
On UNIX, it's currently bad programming practice to embed \e in a program.
This is because there are lots of non-ANSI terminals out there.
However, I know of no non-UNIX environment that has either termcap or
terminfo. Certainly the typical non-UNIX C compiler does not come with
either. While I would prefer to see curses adopted as part of the C
standard, next to stdio, at least as an interface, that apparently isn't
going to happen.
We should also consider that there is an ANSI standard, X3.64, for escape
sequences. Virtually every terminal product that has come out in the past
two years that isn't trying to be upward compatible with something else
conforms to X3.64. This trend will no doubt continue. I expect that in
about 2-3 years, non-ANSI terminals will be rare. This will mean that
simple programs such as the Korn shell, which do editing on the bottom line
without knowing your terminal type, will be able to make a few assumptions
about your terminal capabilities other than \r, \n, and \b. Ditto for
things like the UNIX kernel, which doesn't dare use terminfo or termcap,
but whose tty driver could certainly be spiffed up if it were allowed to
address the cursor and use things like clear-to-eol. Things like clear-screen,
address the cursor on the current line, set or clear a tab, turn on the
printer port, and move the cursor up one position, are pretty safe on a
reasonable implementation of X3.64, even if you don't know the screen size.
The usual complaint is that EBCDIC has no escape character. While this is
true, there is probably an EBCDIC character that will map into escape when
the EBCDIC-ASCII translation is done, so it can still be useful on an IBM
system with an ASCII terminal. This character is probably not 033, but I
don't have a conversion chart handy.
The main reason I see for including \e, \l, and \a is that the resulting
programs will be more readable and easier to write than programs that use
\033 or that use things like ESC "[A".
Mark
------------------------------
Date: Fri, 8 Mar 85 11:05:41 est
From: ihnp4!watmath!atbowler (Alan T. Bowler [SDG])
Subject: What ftell returns
To: std-c@cbosgd.ATT.UUCP
Steve Ludlum writes:
> It is unreasonable to not allow manipulation of the argument
> passed to fseek. What machines do not have long as at least a 32
> bit int. [?] Is it lazy compiler or architecture limitations. [?]
I think the point that was being made, was that in record oriented systems
a 32 bit byte number is not a natural or easy way to encode the current
position. There is of course the other problem that there exist machines
and operating systems which are perfectly happy to support files much
larger than 2**32 bytes, in which case a long is also not sufficient.
------------------------------
End of mod.std.c Digest - Fri, 8 Mar 85 19:57:07 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.