Page 1116
DESCRIPTION
The file /news/lib/control.ctl is used to determine what action is taken when a control message is received. It is read by the parsecontrol script, which is called by all the control scripts. (For an explanation of how the control scripts are invoked, see innd(8).)
The file consists of a series of lines; blank lines and lines beginning with a number sign (#) are ignored. All other lines consist of four fields separated by a colon:
message:from:newsgroups:action
The first field is the name of the message for which this line is valid. It should be either the name of the control message, or the word all to mean that it is valid for all messages.
The second field is a shell-style pattern that matches the e-mail address of the person posting the message. (The poster's address is first converted to lowercase.) The matching is done using the shell's case statement; see sh(1) for details.
If the control message is newgroup or rmgroup, then the third field specifies the shell-style pattern that must match the group being created or removed. If the control message is of a different type, then this field is ignored.
The fourth field specifies what action to take if this line is selected for the message. The following actions are understood:
| doit |
The action requested by the control message should be performed. In most cases, the control script will also send mail to Usenet. |
| doifarg |
If the control message has an argument, this is treated as a doit action. If no argument was given, it is treated as a mail entry. This is used in a sendsys entries script so that a site can request its own newsfeeds(5) entry by posting a sendsys mysite article. On the other hand, sendsys bombs ask that the newsfeeds file be sent; if you use doifarg, such messages will not be processed automatically. |
| doit=file |
The action is performed, but a log entry is written to the specified log file, file. If file is the word mail, then the record is mailed. A null string is equivalent to /dev/null. A pathname that starts with a slash is taken as the absolute filename to use as the log. All other pathnames are written to /var/ log/news/file.log. The log is written by writelog (see newslog(8)). |
| drop | No action is taken; the message is ignored. |
| log | A one-line log notice is sent to standard error. innd normally directs this to the file /var/log/news/errlog. |
| log=file | A log entry is written to the specified log file, file, which is interpreted as described previously. |
| A mail message is sent to the news administrator. |
Lines are matched in order; the last match found in the file is the one that is used. For example, with the following three lines:
newgroup:*:*:drop newgroup:tale@*.uu.net:comp.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:doit newgroup:kre@munnari.oz.au:aus.*:mail
A newgroup coming from tale at a UUNET machine will be honored if it is in the mainstream Usenet hierarchy. If kre posts a newgroup message creating aus.foo, then mail will be sent. All other newgroup messages are ignored.
HISTORY
Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.
SEE ALSO
innd(8), newsfeeds(5), scanlogs(8)
cvs—Concurrent Versions System support files.
Page 1117
SYNOPSIS
$CVSROOT/CVSROOT/commitinfo,v $CVSROOT/CVSROOT/cvsignore,v $CVSROOT/CVSROOT/cvswrappers,v $CVSROOT/CVSROOT/editinfo,v $CVSROOT/CVSROOT/history $CVSROOT/CVSROOT/loginfo,v $CVSROOT/CVSROOT/modules,v $CVSROOT/CVSROOT/rcsinfo,v $CVSROOT/CVSROOT/taginfo,v
DESCRIPTION
cvs is a system for providing source control to hierarchical collections of source directories. Commands and procedures for using cvs are described in cvs(1). cvs manages source repositories, the directories containing master copies of the revision-controlled files, by copying particular revisions of the files to (and modifications back from) developers' private working directories. In terms of file structure, each individual source repository is an immediate subdirectory of $CVSROOT. The files described here are supporting files; they do not have to exist for cvs to operate, but they allow you to make cvs operation more flexible.
You can use the modules file to define symbolic names for collections of source maintained with cvs. If there is no modules file, developers must specify complete pathnames (absolute or relative to $CVSROOT) for the files they want to manage with cvs commands. You can use the commitinfo file to define programs to execute whenever cvs commit is about to execute. These programs are used for "precommit" checking to verify that the modified, added, and removed files are really ready to be committed. Some uses for this check might be to turn off a portion (or all) of the source repository from a particular person or group or perhaps to verify that the changed files conform to the site's standards for coding practice.
You can use the cvswrappers file to record cvs wrapper commands to be used when checking files into and out of the repository. Wrappers allow the file or directory to be processed on the way in and out of cvs. The intended uses are many; one possible use is to reformat a C file before the file is checked in so all the code in the repository looks the same. You can use the loginfo file to define programs to execute after any commit, which writes a log entry for changes in the repository. These logging programs might be used to append the log message to a file or send the log message through electronic mail to a group of developers. You can also post the log message to a particular newsgroup.
You can use the taginfo file to define programs to execute after any tag or rtag operation. These programs might be used to append a message to a file listing the new tag name and the programmer who created it, to send mail to a group of developers, or to post a message to a particular newsgroup. You can use the rcsinfo file to define forms for log messages. You can use the editinfo file to define a program to execute for editing or validating cvs commit log entries. This is most useful when used with a rcsinfo forms specification because it can verify that the proper fields of the form were filled in by the user committing the change. You can use the cvsignore file to specify the default list of files to ignore during update. You can use the history file to record the cvs commands that affect the repository. The creation of this file enables history logging.
FILES
| modules | The modules file records your definitions of names for collections of source code. cvs will use these definitions if you use cvs to check in a file with the right format to $CVSROOT/CVSROOT/modules,v. The modules file can contain blank lines and comments (lines beginning with #) as well as module definitions. Long lines can be continued on the next line by specifying a backslash (\) as the last character on the line. A module definition is a single line of the modules file in either of two formats. In both cases, mname represents the symbolic module name, and the remainder of the line is its definition. |
| mname _a aliases ... | |
| This represents the simplest way of defining a module mname. The _a flags the definition as a simple alias: cvs will treat any use of mname (as a command argument) as if the list of names aliases had been specified instead. aliases may |