Page 1119
|
in order, the tagname, operation (add for tag, mov for tag -F, and del for tag -d), and repository, and any remaining are pairs of filename revision. A nonzero exit of the filter program will cause the tag to be aborted. For commitinfo, the rest of the line is a command-line template to execute. The template can include not only a program name but also whatever list of arguments you want. The full path to the current source repository is appended to the template, followed by the filenames of any files involved in the commit (added, removed, and modified files). For rcsinfo, the rest of the line is the full path to a file that should be loaded into the log message template. For editinfo, the rest of the line is a command-line template to execute. The template can include not only a program name but also whatever list of arguments you want. The full path to the current log message template file is appended to the template. You can use one of two special strings instead of a regular expression: ALL specifies a command-line template that must always be executed, and DEFAULT specifies a command-line template to use if no regular expression is a match. The commitinfo file contains commands to execute before any other commit activity, to allow you to check any conditions that must be satisfied before commit can proceed. The rest of the commit will execute only if all selected commands from this file exit with exit status 0. The rcsinfo file allows you to specify log templates for the commit logging session; you can use this to provide a form to edit when filling out the commit log. The field after the regular expression, in this file, contains filenames (of files containing the logging forms) rather than command templates. The editinfo file allows you to execute a script before the commit starts but after the log information is recorded. These "edit" scripts can verify information recorded in the log file. If the edit script exits with a nonzero exit status, the commit is aborted. The loginfo file contains commands to execute at the end of a commit. The text specified as a commit log message is piped through the command; typical uses include sending mail, filing an article in a newsgroup, or appending to a central file. | |
| cvsignore, .cvsignore |
The default list of files (orsh(1) filename patterns) to ignore during cvs update. At startup time, cvs loads the compiled default list of filename patterns (see cvs(1)). Then the per-repository list included in $CVSROOT/CVSROOT/cvsignore is loaded, if it exists. |
|
Then the per-user list is loaded from $HOME/.cvsignore. Finally, as cvs traverses through your directories, it will load any per-directory .cvsignore files whenever it finds one. These per-directory files are only valid for exactly the directory that contains them, not for any subdirectories. | |
| history |
Create this file in $CVSROOT/CVSROOT to enable history logging (see the description of cvs history). |
SEE ALSO
cvs(1)
COPYING
Copyright " 1992, Cygnus Support, Brian Berliner, and Jeff Polk.
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.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Page 1120
Permission is granted to copy and distribute translations of this manual into another language, under the preceding conditions for modified versions, except that this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English.
12 February 1992
DEVINFO—Device entry database.
DESCRIPTION
DEVINFO is a text file that describes all the possible devices for a system. It is used by MAKEDEV(8) to create special file entries in /dev. It may be named either /dev/DEVINFO or /etc/devinfo. Information about custom local devices, if any, should be placed in DEVINFO.local or /etc/devinfo.local, which has the same syntax.
The file format is free-form. C, C++, and shell comments are understood. There are basically four statements:
| ignore { proc-device... } | This causes the specified names to be ignored if found in /proc/devices. |
| batch { device... } |
This creates a "batch"—a collection of devices that will all be created when the batch is invoked. For example, in the standard DEVINFO, "generic" is a batch. |
| block device-spec | This defines one or more block devices. |
| char device-spec | This defines one or more character devices. |
Here is a sample device-spec:
(std, 1) {
mem (kmem) : 1
null (public) : 3
core -> "/proc/kcore"
}
This example defines a group of devices called std, with major number 1. Running will create all the devices in the group; running, for example, would make just the one device null.
It is possible to specify, instead of just std, something like std=foo. In this case, the stuff on the right-hand side of the equals sign specifies a name from /proc/devices, and the major number will be retrieved from there if present. If an entry from /proc/devices is specified, the explicit major number may be omitted. In this case, if the number is not found in /proc/devices, attempts to create the device will be rejected.
Inside the braces is a list of specific devices. The name in parenthesis is the "class"; this is something specified in MAKEDEV.cfg that determines the ownership and permissions of the special file created. In the preceding example, the device mem was set to have the class kmem, but null was set to be public. Ordinarily, you'd define public to be mode 666 but kmem to be mode 660 and owned by group kmem. The number after the colon is the minor number for this particular device; for instance, 3 for null.
You may also specify a symbolic link with ->. For instance, core was made a link to /proc/kcore. Note that names may contain any characters, but names that contain things other than alphanumerics, dash, and underscore should be put in double quotes.
An entire range of devices can be created. You may specify a range of numbers in brackets:
tty[1-8] (tty) : 1
This creates tty1_tty8 with minor device numbers starting with 1. If you specify the range in hex (prefixed by 0x), the device names will be created numbered in hex, as is normal for ptys. The range may appear inside the name string, but there may only be one range.