📄 1116-1117.html
字号:
<HTML>
<HEAD>
<TITLE>Linux Complete Command Reference:File Formats:EarthWeb Inc.-</TITLE>
</HEAD>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311046 //-->
<!-- TITLE=Linux Complete Command Reference//-->
<!-- AUTHOR=Red Hat//-->
<!-- PUBLISHER=Macmillan Computer Publishing//-->
<!-- IMPRINT=Sams//-->
<!-- CHAPTER=05 //-->
<!-- PAGES=1103-1208 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="1114-1115.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="1118-1118.html">Next</A></CENTER></P>
<A NAME="PAGENUM-1116"><P>Page 1116</P></A>
<P><B>
DESCRIPTION
</B></P>
<P>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).)
</P>
<P>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:
</P>
<!-- CODE SNIP //-->
<PRE>
message:from:newsgroups:action
</PRE>
<!-- END CODE SNIP //-->
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>The fourth field specifies what action to take if this line is selected for the message. The following actions are understood:
</P>
<TABLE>
<TR><TD>
doit
</TD><TD>
The action requested by the control message should be performed. In most cases, the control script <BR>
will also send mail to Usenet.
</TD></TR><TR><TD>
doifarg
</TD><TD>
If the control message has an argument, this is treated as a doit action. If no argument was given, it <BR>
is treated as a mail entry. This is used in a sendsys entries script so that a site can request its own <BR>
newsfeeds(5) entry by posting a sendsys mysite article. On the other hand, sendsys bombs ask that <BR>
the newsfeeds file be sent; if you use doifarg, such messages will not be processed automatically.
</TD></TR><TR><TD>
doit=file
</TD><TD>
The action is performed, but a log entry is written to the specified log file, file. If file is the word <BR>
mail, then the record is mailed. A null string is equivalent to /dev/null. A pathname that starts with <BR>
a slash is taken as the absolute filename to use as the log. All other pathnames are written to /var/<BR>
log/news/file.log. The log is written by writelog (see newslog(8)).
</TD></TR><TR><TD>
drop
</TD><TD>
No action is taken; the message is ignored.
</TD></TR><TR><TD>
log
</TD><TD>
A one-line log notice is sent to standard error.
innd normally directs this to the file
/var/log/news/errlog.
</TD></TR><TR><TD>
log=file
</TD><TD>
A log entry is written to the specified log file,
file, which is interpreted as described previously.
</TD></TR><TR><TD>
mail
</TD><TD>
A mail message is sent to the news administrator.
</TD></TR></TABLE>
<P>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:
</P>
<!-- CODE SNIP //-->
<PRE>
newgroup:*:*:drop
newgroup:tale@*.uu.net:comp.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:doit
newgroup:kre@munnari.oz.au:aus.*:mail
</PRE>
<!-- END CODE SNIP //-->
<P>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.
</P>
<P><B>
HISTORY
</B></P>
<P>Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.
</P>
<P><B>
SEE ALSO
</B></P>
<P>innd(8), newsfeeds(5), scanlogs(8)
</P>
<H3><A NAME="ch05_ 10">
cvs
</A></H3>
<P>cvs—Concurrent Versions System support files.
</P>
<A NAME="PAGENUM-1117"><P>Page 1117</P></A>
<P><B>
SYNOPSIS
</B></P>
<!-- CODE //-->
<PRE>
$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
</PRE>
<!-- END CODE //-->
<P><B>
DESCRIPTION
</B></P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P><B>
FILES
</B></P>
<TABLE>
<TR><TD>
modules
</TD><TD>
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.
</TD></TR><TR><TD>
</TD><TD>
mname _a aliases ...
</TD></TR><TR><TD>
</TD><TD>
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
</TD></TR></TABLE>
<P><CENTER>
<a href="1114-1115.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="1118-1118.html">Next</A></CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -