ch41_02.htm

the unix power tools

efficiency and a "complete" interface - one that allowed doing
everything a serial port could do.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45460"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45462"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45464"
></A
>Berkeley UNIX thus acquired <EM
CLASS="emphasis"
>three</EM
> terminal modes. It retained the
original <EM
CLASS="emphasis"
>raw</EM
> and <EM
CLASS="emphasis"
>cooked</EM
> modes, and added a new one called
<EM
CLASS="emphasis"
>cbreak.</EM
>
[5]
In cbreak mode, some input processing was done, but
most characters were sent on to the application as they arrived. Since
the kernel was not collecting lines, the erase and line-kill characters
were unneeded; these were sent on unchanged. Most of the process
control characters&nbsp;- interrupt, quit, and a new <EM
CLASS="emphasis"
>stop</EM
> or <EM
CLASS="emphasis"
>suspend</EM
>
code&nbsp;- were still interpreted. To allow users to type these codes, a
new &quot;literal next&quot; or &quot;quote&quot; character was introduced. Berkeley
UNIX also added more output processing, including a special translation
option for certain Hazeltine Corporation displays and features such as
proper tab handling, output flush, and word erase.</P
><BLOCKQUOTE
CLASS="footnote"
><P
CLASS="para"
>[5] <A
CLASS="indexterm"
NAME="AUTOID-45472"
></A
>This <EM
CLASS="emphasis"
>cbreak</EM
> mode has sometimes been referred to as &quot;half-baked.&quot;</P
></BLOCKQUOTE
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45479"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45481"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45483"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45485"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45487"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45489"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45491"
></A
>The System V base, on the other hand, dropped the idea of raw mode
entirely. Instead, this system provided an individual control for each
option. The <EM
CLASS="emphasis"
>icanon</EM
> option, for instance, controlled whether input
lines were to be collected or &quot;canonicalized.&quot; The <EM
CLASS="emphasis"
>isig</EM
> option
controlled signals: when off, the <EM
CLASS="emphasis"
>interrupt</EM
> (DEL, or in modern systems,
CTRL-c) and <EM
CLASS="emphasis"
>quit</EM
> characters were just ordinary characters. The
<EM
CLASS="emphasis"
>inpchk</EM
> option controlled input parity checking, and so forth.
Similarly, output processing had individual flags: <EM
CLASS="emphasis"
>ocrnl</EM
> for
carriage return-newline control, <EM
CLASS="emphasis"
>opost</EM
> for output processing in
general. By turning everything off individually, an application could
get the same effect as the old system's raw mode. The kernel also
allowed control over the number of data bits in each serial frame, the
number of stop bits, and so forth.
[6]
Thus, while Berkeley UNIX had nice
line editing, it was incapable of attaching to five-bit Baudot systems.
System V lacked the user interface features, but could talk to almost
anything.</P
><BLOCKQUOTE
CLASS="footnote"
><P
CLASS="para"
>[6] Different systems use anything from five to nine bits in a
serial-port &quot;byte.&quot; Most people, however, do not need to care
about all this. Most systems just use eight bits, either as seven
data bits and a parity check, or as eight data bits without parity.
Thus, most people can ignore these options, and stick with either
&quot;seven bits, even parity&quot; or &quot;eight bits, no parity.&quot;</P
></BLOCKQUOTE
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45503"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45505"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45507"
></A
>Since then, the world has become simpler in one way&nbsp;- those old
printing teletypes are gone nearly everywhere, for instance&nbsp;- but 
more complicated in another. These days, many computers use
bitmapped displays rather than individual remote terminals. UNIX
systems support networking, and use windowing systems such as the
<SPAN
CLASS="link"
>X Window System (<A
CLASS="linkend"
HREF="ch01_31.htm"
TITLE="The X Window System "
>1.31</A
>)</SPAN
>.
These in turn bring a myriad of options, window
managers, look-and-feel, and so on. But they all have one thing in
common: to run old applications, each window or network login must
provide a <EM
CLASS="emphasis"
>virtual terminal</EM
> interface. UNIX systems generally do this
with <EM
CLASS="emphasis"
>pseudo teletypes</EM
> or
<SPAN
CLASS="link"
><EM
CLASS="emphasis"
>pty</EM
>s (<A
CLASS="linkend"
HREF="ch41_08.htm"
TITLE="ptys and Window Systems "
>41.8</A
>)</SPAN
>.
Each <EM
CLASS="emphasis"
>pty</EM
> exists to emulate a
display terminal, which in turn is mainly pretending to be a teletype
printer. (Sometimes one has to wonder where the progress lies.)</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45516"
></A
>A POSIX standardization committee has settled on a standard
interface, both at the UNIX kernel level and for the <EM
CLASS="emphasis"
>stty</EM
>
command.  Most UNIX systems, including Berkeley UNIX,
have moved to embrace this standard. While it leaves a few loose
ends&nbsp;- mainly for reasons involving backwards compatibility for System
V-it allows systems both the flexibility of the System V interface
and the features of the Berkeley approach. This means that while
windows and networks may be emulating ancient teletypes, at least
they are all doing it in the same way.</P
></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="UPT-ART-1140-SECT-1.2"
>41.2.2 Handling Most Characters </A
></H3
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45522"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45525"
></A
>With all that as background, let's take a look at what happens to an
input character, from the time you type it until an
application can react. The details may vary&nbsp;- often wildly&nbsp;- depending
on your system and whether you are using a window, a terminal, a
network, or some combination of all three, but the overall idea is the
same. For simplicity, we will assume you have an ordinary terminal.
We will call this &quot;the terminal&quot; and the kernel's idea of it &quot;the
tty.&quot;</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45529"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45531"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45533"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45535"
></A
>Suppose you type the letter <EM
CLASS="emphasis"
>x</EM
>. The terminal sends the
<SPAN
CLASS="link"
>ASCII code (<A
CLASS="linkend"
HREF="ch51_03.htm"
TITLE="ASCII Characters: Listing and Getting Values "
>51.3</A
>)</SPAN
>
for a lowercase X (120) to the UNIX kernel's tty. The kernel then
looks at the <EM
CLASS="emphasis"
>tty</EM
> state. Assume for the sake of discussion that the tty
is in cooked or icanon mode, and that none of the special
characters has been set to <EM
CLASS="emphasis"
>x</EM
>. Then the letter <CODE
CLASS="literal"
>x</CODE
> is placed in
an input buffer and echoed back to the terminal, causing an <CODE
CLASS="literal"
>x</CODE
> to be
displayed on your screen. But if you really wanted to type a <EM
CLASS="emphasis"
>c</EM
>,
you would now type your
<SPAN
CLASS="link"
>erase character (<A
CLASS="linkend"
HREF="ch05_09.htm"
TITLE="Setting Your Erase, Kill, and Interrupt Characters "
>5.9</A
>)</SPAN
>
(usually CTRL-h, BACKSPACE,
or DELETE, which may or may not all be the same or all different,
depending on your particular terminal or keyboard). The code for this
character will also be sent to the tty; this time it will match your
erase character. The kernel will then remove the last character from
the input buffer. Since this&nbsp;- a lowercase X&nbsp;- is an ordinary printing
character, the kernel will send a single backspace, or the sequence
&quot;backspace space backspace,&quot; to the terminal. This will generally back
the cursor up over the character and then erase it from the screen.
(On a POSIX system, you get the latter by setting 
<EM
CLASS="emphasis"
>echoe</EM
> mode.) Finally, when you type RETURN or
ENTER, your terminal sends an ASCII code 13. Since <EM
CLASS="emphasis"
>icrnl</EM
> is set, the
kernel changes this to 10 (newline), which it then echoes to the
terminal. Since <EM
CLASS="emphasis"
>onlcr</EM
> is set, this sends both a code 13 (carriage
return) and a 10 (linefeed) to the terminal. The kernel sees that 10
is a newline, wraps up the collected buffer, and passes it on to
whatever application is currently reading from the tty.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45549"
></A
>If you turn off <EM
CLASS="emphasis"
>icanon</EM
> (or turn on <EM
CLASS="emphasis"
>cbreak</EM
>), the kernel takes any
partially collected buffer and passes those characters to the
application, then passes on each ordinary input character as it comes
in. The kernel still echoes input back to the terminal. If you turn
off the <EM
CLASS="emphasis"
>echo</EM
> flag in the tty, the kernel will stop doing echoing.
This is how a full-screen editor like <EM
CLASS="emphasis"
>vi</EM
> works: it turns off
<EM
CLASS="emphasis"
>icanon</EM
>, turns off <EM
CLASS="emphasis"
>echo</EM
>, and turns off some, but not all, of the
special
characters. The <EM
CLASS="emphasis"
>vi</EM
> program can then do its own echoing, so that when
you type <CODE
CLASS="literal"
>i</CODE
> to go into insert mode, no <CODE
CLASS="literal"
>i</CODE
> appears on your
terminal.</P
><P
CLASS="para"
>One of several difficult areas involves turning <EM
CLASS="emphasis"
>icanon</EM
> back on. In
particular, there may be some characters you typed at the terminal
while <EM
CLASS="emphasis"
>icanon</EM
> was off. These reached the tty, which packaged them up
and sent them off to an application. The application may not have read
them yet, but as far as the <EM
CLASS="emphasis"
>tty</EM
> is concerned, they are gone. Thus, you
may not be able to recover them for your current input line. Older
Berkeley UNIX systems are able to handle this case, but System V
systems that use the STREAMS interface are not. As long as your system
is fast enough, though, you will never notice, because applications
will always turn <EM
CLASS="emphasis"
>icanon</EM
> on before you can type anything at the
terminal.</P
></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="UPT-ART-1140-SECT-1.3"
>41.2.3 What About TABs? </A
></H3
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-45568"
></A
><A
CLASS="indexterm"
NAME="AUTOID-45570"
></A
>Tabs are another difficult issue. The history here predates computing;
typewriter tabs are sometimes used as the &quot;right&quot; model.
Nonetheless, different terminals behave differently, and different