xref: /netbsd-src/share/man/man4/tty.4 (revision 481fca6e59249d8ffcf24fef7cfbe7b131bfb080)
1.\"	$NetBSD: tty.4,v 1.10 2000/03/23 19:48:29 mycroft Exp $
2.\"
3.\" Copyright (c) 1991, 1992, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. All advertising materials mentioning features or use of this software
15.\"    must display the following acknowledgement:
16.\"	This product includes software developed by the University of
17.\"	California, Berkeley and its contributors.
18.\" 4. Neither the name of the University nor the names of its contributors
19.\"    may be used to endorse or promote products derived from this software
20.\"    without specific prior written permission.
21.\"
22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
25.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32.\" SUCH DAMAGE.
33.\"
34.\"     @(#)tty.4	8.3 (Berkeley) 4/19/94
35.\"
36.Dd August 14, 1992
37.Dt TTY 4
38.Os
39.Sh NAME
40.Nm tty
41.Nd general terminal interface
42.Sh SYNOPSIS
43.Fd #include <sys/ioctl.h>
44.Sh DESCRIPTION
45This section describes the interface to the terminal drivers
46in the system.
47.Ss Terminal Special Files
48Each hardware terminal port on the system usually has two terminal special
49device files associated with it in the directory ``/dev/'' (for
50example, ``/dev/tty03'' and ``/dev/dty03'').
51.Pp
52The ``/dev/ttyXX'' special file is used for dialin modems and terminals.
53When a user logs into
54the system on one of these hardware terminal ports, the system has already
55opened the associated device and prepared the line for normal interactive
56use (see
57.Xr getty 8 .)
58.Pp
59The ``/dev/dtyXX'' special file is a SunOS-compatible dialout device.  Unlike
60the dialin device, opening the dialout device never blocks.  If the
61corresponding dialin device is already opened (not blocked in the open waiting
62for carrier), then the dialout open will fail immediately; otherwise it will
63succeed immediately.  While the dialout device is open, the dialin device may
64not be opened.  If the dialin open is blocking, it will wait until the dialout
65device is closed (and carrier is detected); otherwise it will fail immediately.
66.Pp
67There is also a special case of a terminal file that connects not to
68a hardware terminal port, but to another program on the other side.
69These special terminal devices are called
70.Em ptys
71and provide the mechanism necessary to give users the same interface to the
72system when logging in over a network (using
73.Xr rlogin 1 ,
74or
75.Xr telnet 1
76for example.)  Even in these cases the details of how the terminal
77file was opened and set up is already handled by special software
78in the system.
79Thus, users do not normally need to worry about the details of
80how these lines are opened or used.  Also, these lines are often used
81for dialing out of a system (through an out-calling modem), but again
82the system provides programs that hide the details of accessing
83these terminal special files (see
84.Xr tip 1 ) .
85.Pp
86When an interactive user logs in, the system prepares the line to
87behave in a certain way (called a
88.Em "line discipline" ) ,
89the particular details of which is described in
90.Xr stty 1
91at the command level, and in
92.Xr termios 4
93at the programming level.  A user may be concerned with changing
94settings associated with his particular login terminal and should refer
95to the preceding man pages for the common cases.  The remainder of
96this man page is concerned
97with describing details of using and controlling terminal devices
98at a low level, such as that possibly required by a program wishing
99to provide features similar to those provided by the system.
100.Ss Line disciplines
101A terminal file is used like any other file in the system in that
102it can be opened, read, and written to using standard system
103calls.  For each existing terminal file, there is a software processing module
104called a
105.Em "line discipline"
106is associated with it.  The
107.Em "line discipline"
108essentially glues the low level device driver code with the high
109level generic interface routines (such as
110.Xr read 2
111and
112.Xr write 2 ),
113and is responsible for implementing the semantics associated
114with the device.  When a terminal file is first opened by a program,
115the default
116.Em "line discipline"
117called the
118.Dv termios
119line discipline is associated with the file.  This is the primary
120line discipline that is used in most cases and provides the semantics
121that users normally associate with a terminal.  When the
122.Dv termios
123line discipline is in effect, the terminal file behaves and is
124operated according to the rules described in
125.Xr termios 4 .
126Please refer to that man page for a full description of the terminal
127semantics.
128The operations described here
129generally represent features common
130across all
131.Em "line disciplines" ,
132however some of these calls may not
133make sense in conjunction with a line discipline other than
134.Dv termios ,
135and some may not be supported by the underlying
136hardware (or lack thereof, as in the case of ptys).
137.Ss Terminal File Operations
138All of the following operations are invoked using the
139.Xr ioctl 2
140system call.  Refer to that man page for a description of
141the
142.Em request
143and
144.Em argp
145parameters.
146In addition to the ioctl
147.Em requests
148defined here, the specific line discipline
149in effect will define other
150.Em requests
151specific to it (actually
152.Xr termios 4
153defines them as function calls, not ioctl
154.Em requests . )
155The following section lists the available ioctl requests.  The
156name of the request, a description of its purpose, and the typed
157.Em argp
158parameter (if any)
159are listed.  For example, the first entry says
160.Pp
161.D1 Em "TIOCSETD int *ldisc"
162.Pp
163and would be called on the terminal associated with
164file descriptor zero by the following code fragment:
165.Bd -literal
166	int ldisc;
167
168	ldisc = TTYDISC;
169	ioctl(0, TIOCSETD, &ldisc);
170.Ed
171.Ss Terminal File Request Descriptions
172.Bl -tag -width TIOCGWINSZ
173.It Dv TIOCSETD Fa int *ldisc
174Change to the new line discipline pointed to by
175.Fa ldisc .
176The available line disciplines are listed in
177.Pa Aq sys/ttycom.h
178and currently are:
179.Pp
180.Bl -tag -width TIOCGWINSZ -compact
181.It TTYDISC
182Termios interactive line discipline.
183.It TABLDISC
184Tablet line discipline.
185.It SLIPDISC
186Serial IP line discipline.
187.It PPPDISC
188Point to Point Protocol line discipline.
189.It STRIPDISC
190Starmode Radio IP line discipline.
191.El
192.Pp
193.It Dv TIOCGETD Fa int *ldisc
194Return the current line discipline in the integer pointed to by
195.Fa ldisc .
196.It Dv TIOCSBRK Fa void
197Set the terminal hardware into BREAK condition.
198.It Dv TIOCCBRK Fa void
199Clear the terminal hardware BREAK condition.
200.It Dv TIOCSDTR Fa void
201Assert data terminal ready (DTR).
202.It Dv TIOCCDTR Fa void
203Clear data terminal ready (DTR).
204.It Dv TIOCGPGRP Fa int *tpgrp
205Return the current process group the terminal is associated
206with in the integer pointed to by
207.Fa tpgrp .
208This is the underlying call that implements the
209.Xr termios 4
210.Fn tcgetattr
211call.
212.It Dv TIOCSPGRP Fa int *tpgrp
213Associate the terminal with the process group (as an integer) pointed to by
214.Fa tpgrp .
215This is the underlying call that implements the
216.Xr termios 4
217.Fn tcsetattr
218call.
219.It Dv TIOCGETA Fa struct termios *term
220Place the current value of the termios state associated with the
221device in the termios structure pointed to by
222.Fa term .
223This is the underlying call that implements the
224.Xr termios 4
225.Fn tcgetattr
226call.
227.It Dv TIOCSETA Fa struct termios *term
228Set the termios state associated with the device immediately.
229This is the underlying call that implements the
230.Xr termios 4
231.Fn tcsetattr
232call with the
233.Dv TCSANOW
234option.
235.It Dv TIOCSETAW Fa struct termios *term
236First wait for any output to complete, then set the termios state
237associated with the device.
238This is the underlying call that implements the
239.Xr termios 4
240.Fn tcsetattr
241call with the
242.Dv TCSADRAIN
243option.
244.It Dv TIOCSETAF Fa struct termios *term
245First wait for any output to complete, clear any pending input,
246then set the termios state associated with the device.
247This is the underlying call that implements the
248.Xr termios 4
249.Fn tcsetattr
250call with the
251.Dv TCSAFLUSH
252option.
253.It Dv TIOCOUTQ Fa int *num
254Place the current number of characters in the output queue in the
255integer pointed to by
256.Fa num .
257.It Dv TIOCSTI Fa char *cp
258Simulate typed input.  Pretend as if the terminal received the
259character pointed to by
260.Fa cp .
261.It Dv TIOCNOTTY Fa void
262This call is obsolete but left for compatibility.  In the past, when
263a process that didn't have a controlling terminal (see
264.Em The Controlling Terminal
265in
266.Xr termios 4 )
267first opened a terminal device, it acquired that terminal as its
268controlling terminal.  For some programs this was a hazard as they
269didn't want a controlling terminal in the first place, and this
270provided a mechanism to disassociate the controlling terminal from
271the calling process.  It
272.Em must
273be called by opening the file
274.Pa /dev/tty
275and calling
276.Dv TIOCNOTTY
277on that file descriptor.
278.Pp
279The current system does not allocate a controlling terminal to
280a process on an
281.Fn open
282call: there is a specific ioctl called
283.Dv TIOCSCTTY
284to make a terminal the controlling
285terminal.
286In addition, a program can
287.Fn fork
288and call the
289.Fn setsid
290system call which will place the process into its own session - which
291has the effect of disassociating it from the controlling terminal.  This
292is the new and preferred method for programs to lose their controlling
293terminal.
294.It Dv TIOCSTOP Fa void
295Stop output on the terminal (like typing ^S at the keyboard).
296.It Dv TIOCSTART Fa void
297Start output on the terminal (like typing ^Q at the keyboard).
298.It Dv TIOCSCTTY Fa void
299Make the terminal the controlling terminal for the process (the process
300must not currently have a controlling terminal).
301.It Dv TIOCDRAIN Fa void
302Wait until all output is drained.
303.It Dv TIOCEXCL Fa void
304Set exclusive use on the terminal.  No further opens are permitted
305except by root.  Of course, this means that programs that are run by
306root (or setuid) will not obey the exclusive setting - which limits
307the usefulness of this feature.
308.It Dv TIOCNXCL Fa void
309Clear exclusive use of the terminal.  Further opens are permitted.
310.It Dv TIOCFLUSH Fa int *what
311If the value of the int pointed to by
312.Fa what
313contains the
314.Dv FREAD
315bit as defined in
316.Pa Aq sys/fcntl.h ,
317then all characters in the input queue are cleared.  If it contains
318the
319.Dv FWRITE
320bit, then all characters in the output queue are cleared.  If the
321value of the integer is zero, then it behaves as if both the
322.Dv FREAD
323and
324.Dv FWRITE
325bits were set (i.e. clears both queues).
326.It Dv TIOCGWINSZ Fa struct winsize *ws
327Put the window size information associated with the terminal in the
328.Va winsize
329structure pointed to by
330.Fa ws .
331The window size structure contains the number of rows and columns (and pixels
332if appropriate) of the devices attached to the terminal.  It is set by user software
333and is the means by which most full\&-screen oriented programs determine the
334screen size.  The
335.Va winsize
336structure is defined in
337.Pa Aq sys/ioctl.h .
338.It Dv TIOCSWINSZ Fa struct winsize *ws
339Set the window size associated with the terminal to be the value in
340the
341.Va winsize
342structure pointed to by
343.Fa ws
344(see above).
345.It Dv TIOCCONS Fa int *on
346If
347.Fa on
348points to a non-zero integer, redirect kernel console output (kernel printf's)
349to this terminal.
350If
351.Fa on
352points to a zero integer, redirect kernel console output back to the normal
353console.  This is usually used on workstations to redirect kernel messages
354to a particular window.
355.It Dv TIOCMSET Fa int *state
356The integer pointed to by
357.Fa state
358contains bits that correspond to modem state.  Following is a list
359of defined variables and the modem state they represent:
360.Pp
361.Bl -tag -width TIOCMXCTS -compact
362.It TIOCM_LE
363Line Enable.
364.It TIOCM_DTR
365Data Terminal Ready.
366.It TIOCM_RTS
367Request To Send.
368.It TIOCM_ST
369Secondary Transmit.
370.It TIOCM_SR
371Secondary Receive.
372.It TIOCM_CTS
373Clear To Send.
374.It TIOCM_CAR
375Carrier Detect.
376.It TIOCM_CD
377Carier Detect (synonym).
378.It TIOCM_RNG
379Ring Indication.
380.It TIOCM_RI
381Ring Indication (synonym).
382.It TIOCM_DSR
383Data Set Ready.
384.El
385.Pp
386This call sets the terminal modem state to that represented by
387.Fa state .
388Not all terminals may support this.
389.It Dv TIOCMGET Fa int *state
390Return the current state of the terminal modem lines as represented
391above in the integer pointed to by
392.Fa state .
393.It Dv TIOCMBIS Fa int *state
394The bits in the integer pointed to by
395.Fa state
396represent modem state as described above, however the state is OR-ed
397in with the current state.
398.It Dv TIOCMBIC Fa int *state
399The bits in the integer pointed to by
400.Fa state
401represent modem state as described above, however each bit which is on
402in
403.Fa state
404is cleared in the terminal.
405.It Dv TIOCSFLAGS Fa int *state
406The bits in the integer pointed to by
407.Fa state
408contain bits that correspond to serial port state. Following is a list
409of defined variables and the serial port state they represent:
410.Pp
411.Bl -tag -width TIOCFLAG_SOFTCAR -compact
412.It TIOCFLAG_SOFTCAR
413Ignore hardware carrier.
414.It TIOCFLAG_CLOCAL
415Set clocal on open.
416.It TIOCFLAG_CRTSCTS
417Set crtscts on open.
418.It TIOCFLAG_MDMBUF
419Set mdmbuf on open.
420.El
421.Pp
422This call sets the serial port state to that represented by
423.Fa state .
424Not all serial ports may support this.
425.It Dv TIOCGFLAGS Fa int *state
426Return the current state of the serial port as represented
427above in the integer pointed to by
428.Fa state .
429.El
430.Sh HISTORY
431Separate dialout device files were implemented in SunOS 4.  They were cloned
432by Charles M. Hannum for
433.Nx 1.4 .
434.Sh SEE ALSO
435.Xr getty 8 ,
436.Xr ioctl 2 ,
437.Xr pty 4 ,
438.Xr stty 1 ,
439.Xr termios 4
440