Special Files

INTRODUCTION

This part describes special files.

FILES

/dev/* Device files

AUTHORS

Look at the header of the manual page for the author(s) and copyright conditions. Note that these can be different from page to page.

Linux, 24 July 1993

charsets

charsets—Programmer’s view of character sets and internationalization

DESCRIPTION

Linux is an international operating system. Several of its utilities and device drivers (including the console driver) support multilingual character sets including Latin-alphabet letters with diacritical marks, accents, ligatures, and entire non-Latin alphabets including Greek, Cyrillic, Arabic, and Hebrew.

This manual page presents a programmer’s-eye view of different character-set standards and how they fit together on Linux. Standards discussed include ASCII, ISO 8859, KOI8-R, Unicode, ISO 2022, and ISO 4873.

ASCII

ASCII (American Standard Code for Information) is the original 7-bit character set, originally designed for American English. It is currently described by the ECMA-6 standard.

An ASCII variant replacing the American crosshatch/octothorpe/hash pound symbol with the British pound-sterling symbol is used in Great Britain; when needed, the American and British variants may be distinguished as U.S. ASCII and U.K. ASCII.

As Linux was written for hardware designed in the United States, it natively supports U.S. ASCII.

ISO 8859

ISO 8859 is a series of 10 8-bit character sets, all of which have U.S. ASCII in their low (7-bit) half, invisible control characters in positions 128 to 159, and 96 fixed-width graphics in positions 160-255.

Of these, the most important is ISO 8859-1 (Latin-1). It is natively supported in the Linux console driver, fairly well supported in X11R6, and is the base character set of HTML.

Console support for the other 8859 character sets is available under Linux through user-mode utilities (such as setfont(8)) that modify keyboard bindings and the EGA graphics table and employ the “user mapping” font table in the console driver.

Here are brief descriptions of each set:

KOI8-R

KOI8-R is a non-ISO character set popular in Russia. The lower half is U.S. ASCII; the upper is a Cyrillic character set somewhat better designed than ISO 8859-5.

Console support for KOI8-R is available under Linux through user-mode utilities that modify keyboard bindings and the EGA graphics table, and that employ the “user mapping” font table in the console driver.

UNICODE

Unicode (ISO 10646) is a standard that aims to unambiguously represent every known glyph in every human language. Unicode’s native encoding is 32-bit (older versions used 16 bits). Information on Unicode is available at http://www. unicode.com.

Linux represents Unicode using the 8-bit Unicode Transfer Format (UTF-8). UTF-8 is a variable length encoding of Unicode. It uses 1 byte to code 7 bits, 2 bytes for 11 bits, 3 bytes for 16 bits, 4 bytes for 21 bits, 5 bytes for 26 bits, and 6 bytes for 31 bits.

Let 0, 1, x stand for a zero, one, or arbitrary bit. A byte 0xxxxxxx stands for the Unicode 00000000 0xxxxxxx, which codes the same symbol as the ASCII 0xxxxxxx. Thus, ASCII goes unchanged into UTF-8, and people using only ASCII do not notice any change—not in code, and not in file size.

A byte 110xxxxx is the start of a 2-byte code, and 110xxxxx 10yyyyyy is assembled into 00000xxx xxyyyyyy. A byte 1110xxxx is the start of a 3-byte code, and 1110xxxx 10yyyyyy 10zzzzzz is assembled into xxxxyyyy yyzzzzzz. (When UTF-8 is used to code the 31-bit ISO 10646, then this progression continues up to 6-byte codes.)

For ISO-8859-1 users this means that the characters with high bit set now are coded with two bytes. This tends to expand ordinary text files by one or two percent. There are no conversion problems, however, since the Unicode value of ISO-8859- 1 symbols equals their ISO-8859-1 value (extended by eight leading zero bits). For Japanese users, this means that the 16-bit codes now in common use will take three bytes, and extensive mapping tables are required. Many Japanese therefore prefer

ISO 2022.

Note that UTF-8 is self-synchronizing: 10xxxxxx is a tail, any other byte is the head of a code. Note that the only way ASCII bytes occur in a UTF-8 stream is as themselves. In particular, there are no embedded NULs or /s that form part of some larger code.

Because ASCII, and, in particular, NUL and /, are unchanged, the kernel does not notice that UTF-8 is being used. It does not care at all what the bytes it is handling stand for.

Rendering of Unicode data streams is typically handled through subfont tables that map a subset of Unicode to glyphs. Internally, the kernel uses Unicode to describe the subfont loaded in video RAM. This means that in UTF-8 mode one can use a character set with 512 different symbols. This is not enough for Japanese, Chinese, and Korean, but it is enough for most other purposes.

ISO 2022 AND ISO 4873

The ISO 2022 and 4873 standards describe a font-control model based on VT100 practice. This model is (partially) supported by the Linux kernel and by xterm(1). It is popular in Japan and Korea.

There are four graphic character sets, called G0, G1, G2, and G3, and one of them is the current character set for codes with high bit zero (initially G0), and one of them is the current character set for codes with high bit one (initially G1). Each graphic character set has 94 or 96 characters, and is essentially a 7-bit character set. It uses codes either 040–0177 (041–0176) or 0240–0377 (0241–0376). G0 always has size 94 and uses codes 041–0176.

Switching between character sets is done using the shift functions ˆN (SO or LS1), ˆO (SI or LS0), ESC n (LS2), ESC o (LS3), ESC N (SS2),

ESC O (SS3), ESC ˜ (LS1R), ESC } (LS2R), ESC | (LS3R). The function LSn makes character set Gn the current one for codes with high bit zero. The function LSnR makes character set Gn the current one for codes with high bit one. The function SSn makes character set Gn (n=2 or 3) the current one for the next character only (regardless of the value of its high order bit).

A 94-character set is designated as Gn character set by an escape sequence ESC ( xx (for G0), ESC ) xx (for G1), ESC * xx (for G2), ESC + xx (for G3), where xx is a symbol or a pair of symbols found in the ISO 2375 International Register of Coded Character Sets. For example, ESC ( @ selects the ISO 646 character set as G0, ESC ( A selects the U.K. standard character set (with pound instead of number sign), ESC ( B selects ASCII (with dollar instead of currency sign), ESC ( M selects a character set for African languages, ESC ( ! A selects the Cuban character set, and so on.

A 96-character set is designated as Gn character set by an escape sequence ESC - xx (for G1), ESC . xx (for G2) or ESC / xx (for G3). For example, ESC - G selects the Hebrew alphabet as G1.

A multibyte character set is designated as Gn character set by an escape sequence ESC $ xx or ESC $ ( xx (for G0), ESC $ ) xx (for G1), ESC $ * xx (for G2), ESC $ + xx (for G3). For example, ESC $ ( C selects the Korean character set for G0. The Japanese character set selected by ESC $ B has a more recent version selected by ESC & @ESC $ B.

ISO 4873 stipulates a narrower use of character sets, where G0 is fixed (always ASCII), so that G1, G2, and G3 can only be invoked for codes with the high order bit set. In particular, ˆN and ˆO are not used anymore, ESC ( xx can be used only with xx=B, and ESC ) xx, ESC * xx, ESC + xx are equivalent to ESC - xx, ESC . xx, and ESC / xx, respectively.

SEE ALSO

console(4), console_ioctl(4), console_codes(4)

Linux, 5 November 1996

console

console—Console terminal and virtual consoles

DESCRIPTION

A Linux system has up to 63 virtual consoles (character devices with major number 4 and minor number 1 to 63), usually called /dev/ttyn with 1 n 63. The current console is also addressed by /dev/console or /dev/tty0, the character device with major number 4 and minor number 0. The device files /dev/* are usually created using the script MAKEDEV, or using mknod(1), usually with mode 0622 and owner root.tty.

Before kernel version 1.1.54, the number of virtual consoles was compiled into the kernel (in tty.h: #define NR_CONSOLES 8) and could be changed by editing and recompiling because version 1.1.54 virtual consoles are created on-the-fly, as soon as they are needed.

Common ways to start a process on a console are the following:

■Tell init(8) (in inittab(5)) to start a getty(8) on the console

■Ask open(1) to start a process on the console

■Start X; it will find the first unused console and display its output there. (There is also the ancient doshell(8).)

console_codes 1067

Common ways to switch consoles are the following:

■Use Alt+Fn or Ctrl+Alt+Fn to switch to console n; AltGr+Fn might bring you to console n+12 [here Alt and AltGr refer to the left and right Alt keys, respectively]

■Use Alt+RightArrow or Alt+LeftArrow to cycle through the presently allocated consoles

■Use the program chvt(1). (The key mapping can be set by the user; see loadkeys(1); the preceding key combinations are according to the default settings.)

The command disalloc(8) will free the memory taken by the screen buffers for consoles that no longer have any associated process.

PROPERTIES

Consoles carry a lot of state. I hope to document that some other time. The most important fact is that the consoles simulate vt100 terminals. In particular, a console is reset to the initial state by printing the two characters ESC c. All escape sequences can be found in console codes(4).

FILES

/dev/console

/dev/tty*

SEE ALSO

charsets(4), console_codes(4), console_ioctl(4), mknod(1), tty(4), ttys(4), getty(8), init(8), chvt(1), open(1), disalloc(8), loadkeys(1), resizecons(8), setfont(8), mapscrn(8)

Linux, 31 October 1994

console_codes

console_codes—Linux console escape and control sequences

DESCRIPTION

The Linux console implements a large subset of the VT102 and ECMA-48/ISO 6429/ANSI X3.64 terminal controls, plus certain private-mode sequences for changing the color palette, character-set mapping, and so on. In the following tabular descriptions, the second column gives ECMA-48 or DEC mnemonics (the latter if prefixed with DEC) for the given function. Sequences without a mnemonic are neither ECMA-48 nor VT102.

After all the normal output processing has been done, and a stream of characters arrives at the console driver for actual printing, the first thing that happens is a translation from the code used for processing to the code used for printing.

If the console is in UTF-8 mode, then the incoming bytes are first assembled into 16-bit Unicode codes. Otherwise, each byte is transformed according to the current mapping table (which translates it to a Unicode value). (See the “Character Sets” subsection for discussion.)

In the normal case, the Unicode value is converted to a font index, and this is stored in video memory, so that the corresponding glyph (as found in video ROM) appears on the screen. Note that the use of Unicode (and the design of the PC hardware) allows the use of 512 different glyphs simultaneously.

If the current Unicode value is a control character, or you are currently processing an escape sequence, the value will treated specially. Instead of being turned into a font index and rendered as a glyph, it may trigger cursor movement or other control functions. (See the “Linux Console Controls” subsection.)

It is generally not good practice to hardwire terminal controls into programs. Linux supports a terminfo(5) database of terminal capabilities. Rather than emitting console escape sequences by hand, you will almost always want to use a terminfo-aware screen library or utility such as ncurses(3), tput(1), or reset(1).

ECMA-48 SET GRAPHICS RENDITION

The ECMA-48 SGR sequence ESC [ <parameters> m sets display attributes. Several attributes can be set in the same sequence.

DEC PRIVATE MODE(DECSET/DECRST) SEQUENCES

These are not described in ECMA-48. The Set Mode sequences are listed; the Reset Mode sequences are obtained by replacing the final h by l.

The action of the following ioctls depends on the first byte in the struct pointed to by argp, referred to here as the subcode. These are legal only for the superuser or the owner of the current tty.

RETURN VALUES

-1 for error, and errno is set.

ERRORS

WARNING

Do not regard this man page as documentation of the Linux console ioctls. This is provided for the curious only, as an alternative to reading the source. Ioctls are undocumented Linux internals, liable to be changed without warning. (And indeed, this page more or less describes the situation as of kernel version 1.1.94; there are many minor and not-so-minor differences with earlier versions.)

Very often, ioctls are introduced for communication between the kernel and one particular well-known program (fdisk, hdparm, setserial, tunelp, loadkeys, selection, setfont, and so on), and their behavior will be changed when required by this particular program.

Programs using these ioctls will not be portable to other versions of UNIX, will not work on older versions of Linux, and will not work on future versions of Linux.

Use POSIX functions.

SEE ALSO

kbd_mode(1), loadkeys(1), dumpkeys(1), mknod(1), setleds(1), setmetamode(1), ioperm(2), termios(2), execve(2), fcntl(2), charsets(4), console(4), console_codes(4), mt(4), sd(4), tty(4), ttys(4), vcs(4), vcsa(4), mapscrn(8), setfont(8), resizecons(8),

/usr/include/linux/kd.h, /usr/include/linux/vt.h.

Linux, 18 September 1995

fd

fd—Floppy disk device

CONFIGURATION

Floppy drives are block devices with major number 2. Typically, they are owned by root.floppy (that is, user root, group floppy) and have either mode 0660 (access checking via group membership) or mode 0666 (everybody has access). The minor numbers encode the device type, drive number, and controller number. For each device type (that is, combination of density and track count), there is a base minor number. To this base number, add the drive’s number on its controller and 128 if the drive is on the secondary controller. In the following device tables, n represents the drive number.

WARNING

If you use formats with more tracks than supported by your drive, you may cause it mechanical damage. Trying once if more tracks than the usual 40/80 are supported should not damage it, but no warranty is given for that. Don’t create device entries for those formats to prevent their usage if you are not sure.

fd 1081

Drive-independent device files that automatically detect the media format and capacity are

5.25-inch double density device files:

5.25-inch high density device files:

3.5-inch extra density device files:

DESCRIPTION

fd special files access the floppy disk drives in raw mode. The following ioctl(2) calls are supported by fd devices:

FDCLRPRM clears the media information of a drive (geometry of disk in drive).

FDSETPRM sets the media information of a drive. The media information will be lost when the media is changed.

FDDEFPRM sets the media information of a drive (geometry of disk in drive). The media information will not be lost when the media is changed. This will disable autodetection. In order to re-enable autodetection, you have to issue an FDCLRPRM.

FDGETDRVTYP displays the type of a drive (name parameter). For formats that work in several drive types, FDGETDRVTYP returns a name that is appropriate for the oldest drive type that supports this format.

FDFLUSH invalidates the buffer cache for the given drive. FDFLUSH invalidates the buffer cache for the given drive.

FDSETMAXERRS sets the error thresholds for reporting errors, aborting the operation, recalibrating, resetting, and reading sector by sector.

FDSETMAXERRS gets the current error thresholds. FDGETDRVTYP gets the internal name of the drive. FDWERRORCLR clears the write error statistics.

FDWERRORGET reads the write error statistics. These include the total number of write errors, the location and disk of the first write error, and the location and disk of the last write error. Disks are identified by a generation number that is incremented at (almost) each disk change.

FDTWADDLE switches the drive motor off for a few microseconds. This might be needed in order to access a disk whose sectors are too close together.

FDSETDRVPRM sets various drive parameters. FDGETDRVPRM reads these parameters back.

FDGETDRVSTAT gets the cached drive state (disk changed, write protected et al.) FDPOLLDRVSTAT polls the drive and return its state.

FDGETFDCSTAT gets the floppy controller state.

FDRESET resets the floppy controller under certain conditions. FDRAWCMD sends a raw command to the floppy controller.

For more precise information, consult also the <linux/fd.h> and <linux/fdreg.h> include files, as well as the manual page for floppy control.

NOTES

The various formats allow you to read and write many types of disks. However, if a floppy is formatted with a too small intersector gap, performance may drop, up to needing a few seconds to access an entire track. To prevent this, use interleaved formats. It is not possible to read floppies that are formatted using GCR (group code recording), which is used by Apple II and Macintosh computers (800K disks). Reading floppies that are hard sectored (one hole per sector, with the index hole being a little skewed) is not supported. This used to be common with older 8-inch floppies.

ispell

ispell—Format of ispell dictionaries and affix files

DESCRIPTION

ispell(1) requires two files to define the language that it is spell checking. The first file is a dictionary containing words for the language, and the second is an affix file that defines he meaning of special flags in the dictionary. The two files are combined by buildhash (see spell(1)) and written to a hash file that is not described here.

A raw ispell dictionary (either the main dictionary or your own personal dictionary) contains a list of words, one per line. Each word may optionally be followed by a slash (/) and one or more flags, which modify the root word as explained later. Depending on the options with which ispell was built, case may or may not be significant in either the root word or the flags, independently. Specifically, if the compile-time option CAPITALIZATION is defined, case is significant in the root word; if not, case is ignored in the root word. If the compile-time option MASKBITS is set to a value of 32, case is ignored in the flags; otherwise, case is significant in the flags. Contact your system administrator or ispell maintainer for more information (or use the –vv flag to find out). The dictionary should be sorted with the –f flag of sort(1) before the hash file is built; this is done automatically by unchlist(1), which is the normal way of building dictionaries.

If the dictionary contains words that have string characters (see the affix file documentation, following), they must be written in the format given by the defstringtype statement in the affix file. This will be the case for most non-English languages. Be careful to use this format, rather than that of your favorite formatter, when adding words to a dictionary. If you add words to your personal dictionary during an ispell session, they will automatically be converted to the correct format. This feature can be used to convert an entire dictionary if necessary:

echo qqqqq > dummy.dict

buildhash dummy.dict affix-file dummy.hash

awk ‘fprint “*”gENDfprint “#”g’ old-dict-file \ | ispell -a -T old-dict-string-type \

-d ./dummy.hash -p ./new-dict-file \ > /dev/null

rm dummy.*

The case of the root word controls the case of words accepted by ispell, as follows:

1.If the root word appears only in lowercase (for example, bob), it will be accepted in lowercase, capitalized, or all capitals.

2.If the root word appears capitalized (for example, Robert), it will not be accepted in all lowercase, but will be accepted capitalized or all in capitals.

3.If the root word appears all in capitals (for example, UNIX), it will only be accepted all in capitals.

4.If the root word appears with a “funny” capitalization (for example, ITCorp), a word will be accepted only if it follows that capitalization, or if it appears all in capitals.

5.More than one capitalization of a root word may appear in the dictionary. Flags from different capitalizations are combined using OR.

Redundant capitalizations (for example, bob and Bob) will be combined by buildhash and by ispell (for personal dictionaries), and can be removed from a raw dictionary by munchlist.

For example, the dictionary

bob Robert UNIX ITcorp ITCorp

will accept bob, Bob, BOB, Robert, ROBERT, UNIX, ITcorp, ITCorp, and ITCORP, and will reject all others. Some of the unacceptable forms are bOb, robert, Unix, and ItCorp.

ispell 1085

As mentioned, root words in any dictionary may be extended by flags. Each flag is a single alphabetic character, which represents a prefix or suffix that may be added to the root to form a new word. For example, in an English dictionary the D flag can be added to bathe to make bathed. Because flags are represented as a single bit in the hashed dictionary, this results in significant space savings. The munchlist script will reduce an existing raw dictionary by adding flags when possible.

When a word is extended with an affix, the affix will be accepted only if it appears in the same case as the initial (prefix) or final (suffix) letter of the word. Thus, for example, the entry UNIX/M in the main dictionary (M means add an apostrophe and an s to make a possessive) would accept UNIX’S but would reject UNIX’s. If UNIX’s is legal, it must appear as a separate dictionary entry, and it will not be combined by munchlist. (In general, you don’t need to worry about these things; munchlist guarantees that its output dictionary will accept the same set of words as its input, so all you have to do is add words to the dictionary and occasionally run munchlist to reduce its size.)

As mentioned, the affix definition file describes the affixes associated with particular flags. It also describes the character set used by the language.

Although the affix-definition grammar is designed for a line-oriented layout, it is actually a free-format grammar and can be laid out weirdly if you want. Comments are started by a pound (sharp) sign (#), and continue to the end of the line. Backslashes are supported in the usual fashion (\nnn, plus specials \n, \r, \t, \v, \f, \b, and the new hex format \xnn). Any character with special meaning to the parser can be changed to an uninterpreted token by backslashing it; for example, you can declare a flag named asterisk or colon with flag n*: or flag n::.

The grammar will be presented in a top-down fashion, with discussion of each element. An affix-definition file must contain exactly one table:

table :[headers][prefixes][suffixes]

At least one of prefixes and suffixes is required. They can appear in either order.

headers :[options ] char-sets

The headers describe options global to this dictionary and language. These include the character sets to be used and the formatter, and the defaults for certain ispell flags.

options : { fmtr-stmt | opt-stmt | flag-stmt | num-stmt }

The options statements define the defaults for certain ispell flags and for the character sets used by the formatters.

fmtr-stmt : { nroff-stmt | tex-stmt }

A fmtr-stmt statement describes characters that have special meaning to a formatter. Normally, this statement is not necessary, but some languages may have preempted the usual defaults for use as language-specific characters. In this case, these statements may be used to redefine the special characters expected by the formatter.

nroff-stmt : { nroffchars | troffchars } string

The nroffchars statement allows redefinition of certain nroff control characters. The string given must be exactly five characters long, and must list substitutions for the left and right parentheses, the period, the backslash, and the asterisk. (The right parenthesis is not currently used, but is included for completeness.) For example, the statement:

nroffchars {}.\\*

would replace the left and right parentheses with left and right curly braces for purposes of parsing nroff/troff strings, with no effect on the others (admittedly a contrived example). Note that the backslash is escaped with a backslash.

tex-stmt : { TeXchars | texchars } string

The TeXchars statement allows redefinition of certain TeX/LaTeX control characters. The string given must be exactly thirteen characters long, and must list substitutions for the left and right parentheses, the left and right square brackets, the left and right curly braces, the left and right angle brackets, the backslash, the dollar sign, the asterisk, the period or dot, and the percent sign. For example, the statement:

texchars ()\[]<\><\>\\$*.%

would replace the functions of the left and right curly braces with the left and right angle brackets for purposes of parsing TeX/LaTeX constructs, while retaining their functions for the tib bibliographic preprocessor. Note that the backslash, the left square bracket, and the right angle bracket must be escaped with a backslash.

opt-stmt : { cmpnd-stmt | aff-stmt } cmpnd-stmt : compoundwords compound-opt aff-stmt : allaffixes on-or-off on-or-off : { on | off }

compound-opt : { on-or-off | controlled character }

An opt-stmt, used in the preceding code, controls certain ispell defaults that are best made language-specific. The allaffixes statement controls the default for the –P and –m options to ispell. If allaffixes is turned off (the default), ispell will default to the behavior of the –P flag: root/affix suggestions will only be made if there are no “near misses.” If allaffixes is turned on, ispell will default to the behavior of the –m flag: root/affix suggestions will always be made.

The compoundwords statement controls the default for the –B and –C options to ispell. If compoundwords is turned off (the default), ispell will default to the behavior of the –B flag: run-together words will be reported as errors. If compoundwords is turned on, ispell will default to the behavior of the –C flag: run-together words will be considered as compounds if both are in the dictionary. This is useful for languages such as German and Norwegian, which form large numbers of compound words. Finally, if compoundwords is set to controlled, only words marked with the flag indicated by character (which should not be otherwise used) will be allowed to participate in compound formation. Because this option requires the flags to be specified in the dictionary, it is not available from the command line.

flag-stmt : flagmarker character

The flagmarker statement describes the character that is used to separate affix flags from the root word in a raw dictionary file. This must be a character that is not found in any word (including in string characters; see following). The default is / because this character is not normally used to represent special characters in any language.

num-stmt : compoundmin digit

The compoundmin statement controls the length of the two components of a compound word. This only has an effect if compoundwords is turned on or if the –C flag is given to ispell. In that case, only words at least as long as the given minimum will be accepted as components of a compound. The default is 3 characters.

char-sets : norm-sets [ alt-sets ]

The character-set section describes the characters that can be part of a word, and defines their collating order. There must always be a definition of “normal” character sets; in addition, there may be one or more partial definitions of “alternate” sets that are used with various text formatters.

norm-sets :[deftype ] charset-group

A “normal” character set may optionally begin with a definition of the file suffixes that make use of this set. Following this are one or more character-set declarations.

deftype : defstringtype name deformatter suffix*

The defstringtype declaration gives a list of file suffixes that should make use of the default string characters defined as part of the base character set; it is only necessary if string characters are being defined. The name parameter is a string giving the unique name associated with these suffixes; often it is a formatter name. If the formatter is a member of the troff family, nroff should be used for the name associated with the most popular macro package; members of the TeX family should use tex. Other names may be chosen freely, but they should be kept simple, as they are used in ispell’s –T switch to specify a formatter type. The deformatter parameter specifies the deformatting style to use when processing files with the given suffixes. Currently, this must be either tex or nroff. The suffix parameters are a whitespace-separated list of strings which, if present at the end of a filename, indicate that the associated set of string characters should be used by default for this file. For example, the suffix list for the troff family typically includes suffixes such as .ms, .me, .mm, and so on.

charset-group : { char-stmt | string-stmt | dup-stmt}*

ispell 1087

A char-stmt describes single characters; a string-stmt describes characters that must appear together as a string, and which usually represent a single character in the target language. Either may also describe conversion between uppercase and lowercase. A dup-stmt is used to describe alternate forms of string characters, so that a single dictionary may be used with several formatting programs that use different conventions for representing non-ASCII characters.

Characters described with the boundarychars statement are considered part of a word only if they appear singly, embedded between characters declared with the wordchars or stringchar statements. For example, if the hyphen is a boundary character (useful in French), the string foo-bar would be a single word, but -foo would be the same as foo, and foo–bar would be two words separated by nonword characters.

If two ranges or strings are given in a char-stmt or string-stmt, the first describes characters that are interpreted as lowercase and the second describes uppercase. In the case of a stringchar statement, the two strings must be of the same length. Also, in a stringchar statement, the actual strings may contain both uppercase and characters themselves without difficulty; for instance, the statement:

stringchar “\\*(sS” “\\*(Ss”

is legal and will not interfere with (or be interfered with by) other declarations of “s” and “S” as lowercase and uppercase, respectively.

A final note on string characters: some languages collate certain special characters as if they were strings. For example, the German “a-umlaut” is traditionally sorted as if it were ae. ispell is not capable of this; each character must be treated as an individual entity. So in certain cases, ispell will sort a list of words into a different order than the standard “dictionary” order for the target language.

alt-sets : alttype [ alt-stmt*]

Because different formatters use different notations to represent non-ASCII characters, ispell must be aware of the representations used by these formatters. These are declared as alternate sets of string characters.

alttype : altstringtype name suffix*

The altstringtype statement introduces each set by declaring the associated formatter name and filename suffix list. This name and list are interpreted exactly as in the defstringtype statement. Following this header are one or more alt-stmts that declare the alternate string characters used by this formatter.

alt-stmt : altstringchar alt-string std-string

The altstringchar statement describes alternate representations for string characters. For example, the –mm macro package of troff represents the German “a-umlaut” as a\*:, while TeX uses the sequence \”a. If the troff versions are declared as the standard versions using stringchar, the TeX versions may be declared as alternates by using the statement:

altstringchar \\\”a a\\*

When the altstringchar statement is used to specify alternate forms, all forms for a particular formatter must be declared together as a group. Also, each formatter or macro package must provide a complete set of characters, both uppercase and lowercase, and the character sequences used for each formatter must be completely distinct. Character sequences that describe uppercase and lowercase versions of the same printable character must also be the same length. It may be necessary to define some new macros for a given formatter to satisfy these restrictions. (The current version of buildhash does not enforce these restrictions, but failure to obey them may result in errors being introduced into files that are processed with ispell.)

An important minor point is that ispell assumes that all characters declared as wordchars or boundarychars will occupy exactly one position on the terminal screen.

A single character-set statement can declare either a single character or a contiguous range of characters. A range is given as in egrep and the shell: [a-z] means lowercase alphabetics; [ˆa-z] means all but lowercase, and so on. All character-set statements are combined (unioned) to produce the final list of characters that may be part of a word. The collating order of the characters is defined by the order of their declaration; if a range is used, the characters are considered to have been declared in ASCII order. Characters that have case are collated next to each other, with the uppercase character first.

The character-declaration statements have a rather strange behavior caused by the need to match each lowercase character with its uppercase equivalent. In any given wordchars or boundarychars statement, the characters in each range are first sorted into ASCII collating sequence, then matched one-for-one with the other range. (The two ranges must have the same number of characters). Thus, for example, the two statements:

wordchars [aeiou] [AEIOU] wordchars [aeiou] [UOIEA]

would produce exactly the same effect. To get the vowels to match up “wrong,” you would have to use separate statements:

wordchars a U wordchars e O wordchars i I wordchars o E wordchars u A

which would cause uppercase e to be O, and lowercase 0 to be e. This should normally be a problem only with languages that have been forced to use a strange ASCII collating sequence. If your uppercase and lowercase letters both collate in the same order, you shouldn’t have to worry about this “feature.”

The prefixes and suffixes sections have exactly the same syntax, except for the introductory keyword:

prefixes : prefixes flagdef* suffixes : suffixes flagdef* flagdef : flag [*jÚ] char : repl *

A prefix or suffix table consists of an introductory keyword and a list of flag definitions. Flags can be defined more than once, in which case the definitions are combined. Each flag controls one or more repls (replacements), which are conditionally applied to the beginnings or endings of various words.

Flags are named by a single character char. Depending on a configuration option, this character can be either any uppercase letter (the default configuration) or any 7-bit ASCII character. Most languages should be able to get along with just 26 flags.

A flag character may be prefixed with one or more option characters. (If you wish to use one of the option characters as a flag character, simply enclose it in double quotes.)

The asterisk (*) option means that this flag participates in cross-product formation. This only matters if the file contains both prefix and suffix tables. If so, all prefixes and suffixes marked with an asterisk will be applied in all cross-combinations to the root word. For example, consider the root fix with prefixes pre and in, and suffixes es and ed. If all flags controlling these prefixes and suffixes are marked with an asterisk, then the single root fix would also generate prefix, prefixes, prefixed, infix, infixes, infixed, fix, fixes, and fixed. Cross-product formation can produce a large number of words quickly, some of which may be illegal, so watch out. If cross-products produce illegal words, munchlist will not produce those flag combinations, and the flag will not be useful.

repl : condition* > [ - strip-string , ] append-string

The ~ option specifies that the associated flag is only active when a compound word is being formed. This is useful in a language like German, in which the form of a word sometimes changes inside a compound.

A repl is a conditional rule for modifying a root word. Up to eight conditions may be specified. If the conditions are satisfied, the rules on the rightside of the repl are applied, as follows:

1.If a strip-string is given, it is first stripped from the beginning or ending (as appropriate) of the root word.

2.The append-string is added at that point.

ispell 1089

For example, the condition . means “any word”, and the condition Y means “any word ending in Y.” The following (suffix) replacements:

. > MENT Y > -Y,IES

would change induce to inducement and fly to flies. (If they were controlled by the same flag, they would also change fly to flyment, which might not be what was wanted. munchlist can be used to protect against this sort of problem; see the command sequence given in the next paragraph.)

No matter how much you might want it, the strings on the right must be strings of specific characters, not ranges. The reasons are rooted deeply in the way ispell works, and it would be difficult or impossible to provide for more flexibility. For example, you might want to write:

[EY] > -[EY],IES

This will not work. Instead, you must use two separate rules:

E > -E,IES

Y > -Y,IES

The application of repls can be restricted to certain words with conditions:

condition : { . | character | range }

A condition is a restriction on the characters that adjoin, and/or are replaced by, the right-hand side of the repl. Up to eight conditions may be given, which should be enough context for anyone. The right-hand side will be applied only

if the conditions in the repl are satisfied. The conditions also implicitly define a length; roots shorter than the number of conditions will not pass the test. (As a special case, a condition of a single dot defines a length of zero, so that the rule applies to all words indiscriminately.) This length is independent of the separate test that insists that all flags produce an output word length of at least four.

Conditions that are single characters should be separated by whitespace. For example, to specify words ending in ED, write this:

E D> -ED,ING # As in covered > covering

If you write this:

ED > -ED,ING

the effect will be the same as

[ED] > -ED,ING

As a final, minor but important point, it is sometimes useful to rebuild a dictionary file using an incompatible suffix file. For example, suppose you expand the R flag to generate “er” and “ers” (thus making the Z flag somewhat obsolete). To build a new dictionary newdict that using new affixes will accept exactly the same list of words as the old list olddict did using old affixes, the –c switch of munchlist is useful, as in the following example:

$ munchlist -c oldaffixes -l newaffixes olddict > newdict

If you use this procedure, your new dictionary will always accept the same list the original did, even if you badly screwed up the affix file. This is because munchlist compares the words generated by a flag with the original word list and refuses to use any flags that generate illegal words. (Don’t forget that the munchlist step takes a long time and eats up temporary file space.)

EXAMPLES

As an example of conditional suffixes, here is the specification of the S flag from the English affix file:

flag *S:

[ˆAEIOU]Y > -Y,IES # As in imply > implies [AEIOU]Y > S # As in convey > conveys [SXZH] > ES # As in fix > fixes

[ˆSXZHY] > S #As in bat > bats

Byte addresses in mem are interpreted as physical memory addresses. References to non-existent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

It is typically created by

mknod -m 660 /dev/mem c 1 1 chown root.mem /dev/mem

The file kmem is the same as mem, except that the kernel virtual memory rather than physical memory is accessed.

It is typically created by

mknod -m 640 /dev/kmem c 1 2 chown root.mem /dev/kmem

port is similar to mem, but the IO ports are accessed.

It is typically created by

mknod -m 660 /dev/port c 1 4 chown root.mem /dev/port

FILES

/dev/mem

/dev/kmem

/dev/port

SEE ALSO

mknod(1), chown(1), ioperm(2)

Linux, 21 November 1992

mouse

mouse—Serial mouse interface.

CONFIG

Serial mice are connected to a serial RS232/V24 dialout line; see cua(4) for a description.

DESCRIPTION

The pinout of the usual 9 pin plug as used for serial mice is

This is the specification; in fact, 9 V suffices with most mice.

The mouse driver can recognize a mouse by dropping RTS to low. About 14ms later, the mouse will send 0x4D on the data line. After a further 63ms, Microsoft-compatible mice will send 0x33. Other mice send different values.

mouse 1093

The relative mouse movement is sent as dx (positive means right) and dy (positive means down). Various mice can operate at different speeds. To select speeds, cycle through the speeds 9600, 4800, 2400, and 1200 bits/sec, each time writing the two characters from the table below and waiting 0.1 seconds. The following table shows available speeds and the strings that select them:

The first byte of a data packet can be used to synchronization purposes.

MICROSOFT PROTOCOL

The Microsoft protocol uses 1 start bit, 7 data bits, no parity, and 1 stop bit at the speed of 1200 bits/sec. Data is sent to RxD in 3-byte packets. The dx and dy movements are sent as two’s-complement, lb (rb) is set when the left (right) button is pressed:

Original Microsoft mice have only two buttons. However, there are some three-button mice that also use the Microsoft protocol. Pressing the third button is reported by sending a packet with zero movement and no buttons pressed.

MOUSESYSTEMS PROTOCOL

The MouseSystems protocol uses 1 start bit, 8 data bits, no parity, and 2 stop bits at the speed of 1200 bits/sec. Data is sent to RxD in 5-byte packets. dx is sent as the sum of the two two’s-complement values, dy is send as negated sum of the two two’s-complement values. lb (mb, rb) is cleared when the left (middle, right) button is pressed:

SUN PROTOCOL

The Sun protocol uses 1 start bit, 8 data bits, no parity, and 2 stop bits at the speed of 1200 bits/sec. Data is sent to RxD in 3-byte packets. dx is sent as single two’s-complement value, dy as negated two’s-complement value. lb (mb, rb) is cleared when the left (middle, right) button is pressed:

FILES

/dev/sd[a-h]: The whole device

/dev/sd[a-h][0-8]: Individual block partitions

SEE ALSO

scsi(4)

17 December 1992

st

st—SCSI tape device.

SYNOPSIS

#include <sys/mtio.h>

int ioctl(int fd, int request [, (void *)arg3]) int ioctl(int fd, MTIOCTOP, (struct mtop *)mt_cmd)

int ioctl(int fd, MTIOCGET, (struct mtget *)mt_status) int ioctl(int fd, MTIOCPOS, (struct mtpos *)mt_pos)

DESCRIPTION

The st driver provides the interface to a variety of SCSI tape devices. Currently, the driver takes control of all detected devices of type sequential-access. The st driver uses major device number 9.

Each device uses two minor device numbers: a principal minor device number, n, assigned sequentially in order of detection, and a no-rewind device number, (n + 128). Devices opened using the principal device number are sent a REWIND command when they are closed. Devices opened using the no-rewind device number are not. Options such as density or block size are not coded in the minor device number. These options must be set by explicit ioctl() calls and remain in effect when the device is closed and reopened.

Devices are typically created by

mknod -m 660 /dev/st0 c 9 0 mknod -m 660 /dev/st1 c 9 1 mknod -m 660 /dev/nst0 c 9 128 mknod -m 660 /dev/nst1 c 9 129

There is no corresponding block device. The character device provides buffering and read-ahead by default and supports reads and writes of arbitrary size (limited by the driver’s internal buffer size, which defaults to 32768 bytes but can be changed either by using a kernel startup option or by changing a compile-time constant).

Device /dev/tape is usually created as a hard or soft link to the default tape device on the system.

st 1097

ioctlS

The driver supports three ioctl requests. Requests not recognized by the st driver are passed to the scsi driver. The definitions below are from /usr/include/linux/mtio.h:

MTIOCTOP: PERFORM A TAPE OPERATION

This request takes an argument of type (struct mtop *). Not all drives support all operations. The driver returns an EIO error if the drive rejects an operation.

/* Structure for MTIOCTOP – mag tape op command: */ struct mtop {

short mt_op; /* operations defined below */ int mt_count; /* how many of them */

};

mt_fileno reports the current file number (zero-based). This value is set to -1 when the file number is unknown (such as after MTBSS or MTSEEK).

mt_blkno reports the block number (zero-based) within the current file. This value is set to -1 when the block number is unknown (such as after

MTBSF, MTBSS, or MTSEEK).

MTIOCPOS: GET TAPE POSITION

This request takes an argument of type (struct mtpos *) and reports the drive’s notion of the current tape block number, which is not the same as mt_blkno returned by MTIOCGET. This drive must be a SCSI-2 drive that supports the READ POSITION command (device-specific address) or a Tandberg-compatible SCSI-1 drive (Tandberg, Archive Viper, Wangtek,…).

/* structure for MTIOCPOS - mag tape get position command */ struct mtpos {

long mt_blkno; /* current block number */ };

RETURN VALUE

COPYRIGHT

Copyright 1995, Robert K. Nichols.

Permission is granted to make and distribute verbatim copies of this manual, provided the copyright notice and this permission notice are preserved on all copies. Additional permissions are contained in the header of the source file.

SEE ALSO

mt(1)

Linux 1.1.86, 31 January 1995

tty

tty—Controlling terminal.

DESCRIPTION

The file /dev/tty is a character file with major number 5 and minor number 0, usually of mode 0666 and owner.group root.tty. It is a synonym for the controlling terminal of a process, if any.

In addition to the ioctl() requests supported by the device that tty refers to, the following ioctl() request is supported:

FILES

/dev/tty

SEE ALSO

mknod(1), chown(1), getty(1), termios(2), console(4), ttys(4)

Linux, 21 January 1992

ttys

ttys—Serial terminal lines.

DESCRIPTION

ttyS[0-3] are character devices for the serial terminal lines.

They are typically created by

mknod -m 660 /dev/ttyS0 c 4 64 # base address 0x03f8 mknod -m 660 /dev/ttyS1 c 4 65 # base address 0x02f8 mknod -m 660 /dev/ttyS2 c 4 66 # base address 0x03e8 mknod -m 660 /dev/ttyS3 c 4 67 # base address 0x02e8 chown root.tty /dev/ttyS[0-3]

FILES

/dev/ttyS[0-3]

SEE ALSO

mknod(1), chown(1), getty(1), tty(4)

Linux, 19 December 1992

vcs, vcsa

vcs, vcsa—Virtual console memory.

DESCRIPTION

/dev/vcs0 is a character device with major number 7 and minor number 0, usually of mode 0644 and owner root.tty. It refers to the memory of the currently displayed virtual console terminal.

/dev/vcs[1-63] are character devices for virtual console terminals; they have major number 7 and minor number 1 to 63, usually mode 0644 and owner root.tty. /dev/vcsa[0-63] are the same but include attributes and are prefixed with four bytes, giving the screen dimensions and cursor position: lines, columns, x, y.(x = y = 0 at the top-left corner of the screen.)