Page 222
| TIP |
If you ever find that your terminal state has been messed up, then you can usually fix this with the command stty sane and Ctrl+J. Note that the command is ended with Ctrl+J, rather than Enter (which is the same as Ctrl+M). This is because the icrnl option might have been turned off. This is fixed again with stty sane. GNU bash will always cope with CRs that have not been converted to LF anyway, but some other programs won't. |
Programs can turn off the processing that the line driver does by default; the resulting behavior (raw mode) allows programs to read unprocessed input from the terminal driver (for example, CR is not mapped to LF), and control characters don't produce the signals described in the table earlier in this section. The stty sane command will return things to normal.
Although the terminal interfaces used most commonly under Linux are the console driver and the pseudo-terminals driven by programs like xterm, script, and expect, the original terminal interface involved serial communications. In fact, this still lingers on; a pseudo-tty associated with an xterm window still has an associated baud rate as shown in the example in the section "The Terminal Device Driver." Changing this baud rate has no actual effect, though. For real serial ports, however, the baud rate and many other parameters have a direct relevance. The device nodes relating to the serial ports are composed of two "teams," with the names /dev/cua* and /dev/ttyS*. These allow the same serial hardware to be used for both incoming and outgoing serial connections, as explained later in the section "Using Modems."
Serial port configuration is mostly done either with the stty command or directly by programs using the interface outlined in the termios manual page. The stty command offers almost all the configuration possibilities provided by termios; however, there are configuration issues for serial hardware that are not addressed by stty. The setserial command allows the configuration of the correct IRQ settings for each serial port and of extra-fast baud rates that the standard termios specification doesn't provide. For more detailed information, refer to the Linux Serial-HOWTO and the manual page for setserial.
Modems (other than "WinModems") are very flexible devices. They allow dial-up terminal access and wide area networking, and they also often allow the sending and receiving of faxes
Page 223
or voice-mail. The two "teams" of serial device nodes mentioned earlier are intended specifically for good modem support, and they look like this:
$ ls -l /dev/ttyS* /dev/cua* /dev/mo* crw-rw---- 1 root uucp 5, 64 Jan 1 1980 /dev/cua0 crw-rw---- 1 root uucp 5, 65 Jan 1 1980 /dev/cua1 crw-rw---- 1 root uucp 5, 66 Jan 1 1980 /dev/cua2 crw-rw---- 1 root uucp 5, 67 Jan 1 1980 /dev/cua3 lrwxrwxrwx 1 root uucp 4 Jun 7 14:16 /dev/modem -> cua2 lrwxrwxrwx 1 root root 10 Sep 6 1996 /dev/mouse -> /dev/ttyS0 crw-r--r-- 1 root root 4, 64 Nov 1 08:56 /dev/ttyS0 crw-r--r-- 1 root root 4, 65 May 29 1995 /dev/ttyS1 crw-r--r-- 1 root root 4, 66 Jan 1 1980 /dev/ttyS2 crw-r--r-- 1 root root 4, 67 Jan 1 1980 /dev/ttyS3
The /dev/cua* devices are intended for use for dialing out, and the /dev/ttyS* devices are intended for dialing in. A process such as getty can be waiting for an open system call to complete (that is, waiting for the modem to signal that there is an incoming call) on the /dev/ttyS0 device while you are opening the corresponding device /dev/cua0, which refers to the same hardware. Because there can't be an incoming call on that line while you're using the modem, getty continues to wait. Lock files keep everyone from trying to use the same device at the same time.
These days, internetworking is the most common use for modems by far. There are many resources that will help you set up your machine for Internet access via a modem. See the section "Connecting to the Net with PPP" in Chapter 13. Other resources include the Red Hat PPP-Tips document, which can be found in the support section of Red Hat's Web site, the EzPPP package, and the ISP-HOOKUP and PPP HOWTOS. There are also a large number of useful mini-HOWTOs that each help with more specific things; these include the Diald, Dip+SLiRP+CSLIP, Dynamic-IP-Hacks, IP-Masquerade, PPP-over-ISDN, PPP-over-minicom, SLIP+proxyARP, and Tiny-News Linux mini-HOWTOs. If, on the other hand, you send and receive e-mail by UUCP rather than Internet protocols, you should start by reading the Linux UUCP HOWTO and the Linux Sendmail+UUCP mini-HOWTO.
Not all SCSI devices are hard disks, CD-ROM drives, or tape drives. Some are optical scanners, CD-ROM recorders, or even electron microscopes. The kernel can't possibly abstract the interfaces for all possible SCSI devices, so it gives user programs direct access to SCSI hardware via the generic SCSI devices. These enable programs to send arbitrary SCSI commands to hardware. Although this offers the opportunity of wreaking havoc by mistake, it also offers the capability of driving all sorts of interesting hardware, of which the principal examples are CD-ROM recorders. The SCSI device nodes all have names starting with /dev/sg. SCSI commands are sent to the devices by writing data to the device, and the results are read back by reading from the device.
Page 224
CD-ROM recorders are devices for recording data on special media that can be read in ordinary CD-ROM drives. There are two stages in the writing of a CD: the generation of the CD image and the writing of that image to the media.
The surface of a CD-R (recordable CD) is only writable once, so if mkisofs worked like the other mkfs tools it would always generate image files representing empty CDs. For this reason, mkisofs populates the filesystem with files as it generates the image file.
The CD image file is produced by the mkisofs program, which generates the structures for an ISO9660 filesystem and populates it with the files from a directory tree. CDs are not writable in the same sense as block devices; this is why they are not actually block devices. The image file must be written to the CD-R with a specialized program, cdwrite, which understands all the various proprietary schemes used for driving CD writers. All the CD writers supported by Linux (as of version 2.0.30 of the kernel) are SCSI devices, so the kernel accommodates this by providing access to the generic SCSI device interface that enables a program to send SCSI commands to these devices.
While burning (writing) a CD, it is usually important that the flow of data to the writer keeps up with the speed at which the writer is going; otherwise, if the writer runs out of data to write, the CD-R is ruined. For this reason, it is usual to use mkisofs to generate an image file and then separately use cdwrite to write this image file to the CD writer.
It is possible to use a pipe to send the data from mkisofs directly to cdwrite. This often works either because a fast machine can ensure that mkisofs supplies the data fast enough to keep the CD writer busy or because the CD writer is not sensitive to data underruns. (Some of the more expensive ones have internal hard disks to which the data is written as an intermediate stage.) This technique is not recommended, however, because the generation of the intermediate image file has other benefits; it enables you to test your CD image before the final writing of the data takes place.
Just as you can use mkfs to create a filesystem inside an ordinary file, you can mount filesystems contained in ordinary files by using the loopback device driver described previously. The first example of mounting a loopback filesystem is a demonstration of how you can test a CD image.
There are several other varieties of character devices, some which are used frequently. For example, /dev/null is used very frequently.