Page 63
DESCRIPTION
This manual page documents the GNU version of chown. chown changes the user and/or group ownership of each given file, according to its first nonoption argument, which is interpreted as follows. If only a username (or numeric user ID) is given, that user is made the owner of each given file, and the files' group is not changed. If the username is followed by a colon or dot and a group name (or numeric group ID), with no spaces between them, the group ownership of the files is changed as well. If a colon or dot but no group name follows the username, that user is made the owner of the files and the group of the files is changed to that user's login group. If the colon or dot and group are given, but the username is omitted, only the group of the files is changed; in this case, chown performs the same function as chgrp.
OPTIONS
| _c, —changes | Verbosely describe only files whose ownership actually changes. |
| _f, —silent, —quiet | Do not print error messages about files whose ownership cannot be changed. |
| _v, —verbose | Verbosely describe ownership changes. |
| _R, —recursive | Recursively change ownership of directories and their contents. |
| —help | Print a usage message on standard output and exit successfully. |
| —version | Print version information on standard output then exit successfully. |
GNU File Utilities
chsh—Change your login shell
SYNOPSIS
chsh [ _s shell ] [ _l ] [ _u ] [ _v ] [ username ]
DESCRIPTION
chsh is used to change your login shell. If a shell is not given on the command line, chsh prompts for one.
VALID SHELLS
chsh will accept the full pathname of any executable file on the system. However, it will issue a warning if the shell is not listed in the /etc/shells file.
OPTIONS
| _s, —shell | Specify your login shell. |
| _l, —list-shells | Print the list of shells listed in /etc/shells and exit. |
| _u, —help | Print a usage message and exit. |
| -v, —version | Print version information and exit. |
SEE ALSO
login(1), passwd(5), shells(5)
AUTHOR
Salvatore Valente (<svalente@mit.edu>)
chsh, 13 October 1994
Page 64
ci—Check in RCS revisions
SYNOPSISci [options] file ...
DESCRIPTION
ci stores new revisions into RCS files. Each pathname matching an RCS suffix is taken to be an RCS file. All others are assumed to be working files containing new revisions. ci deposits the contents of each working file into the corresponding RCS file. If only a working file is given, ci tries to find the corresponding RCS file in an RCS subdirectory and then in the working file's directory. (For more details, see "File Naming," later in this manual page.)
For ci to work, the caller's login must be on the access list, unless the access list is empty or the caller is the superuser or the owner of the file. To append a new revision to an existing branch, the tip revision on that branch must be locked by the caller. Otherwise, only a new branch can be created. This restriction is not enforced for the owner of the file if non-strict locking is used; see rcs(1). A lock held by someone else can be broken with the rcs command.
Unless the _f option is given, ci checks whether the revision to be deposited differs from the preceding one. If not, instead of creating a new revision ci reverts to the preceding one. To revert, ordinary ci removes the working file and any lock; ci _l keeps and ci _u removes any lock, and then they both generate a new working file much as if co _l or co _u had been applied to the preceding revision. When reverting, any _n and -s options apply to the preceding revision.
For each revision deposited, ci prompts for a log message. The log message should summarize the change and must be terminated by end-of-file or by a line containing . by itself. If several files are checked in, ci asks whether to reuse the previous log message. If the standard input is not a terminal, ci suppresses the prompt and uses the same log message for all files. (See also _m.)
If the RCS file does not exist, ci creates it and deposits the contents of the working file as the initial revision (default number: 1.1). The access list is initialized to empty. Instead of the log message, ci requests descriptive text (See _t.)
The number rev of the deposited revision can be given by any of the options _f, _i, _I, _j, _k, _l, _M, _q, _r, or _u. rev can be symbolic, numeric, or mixed. Symbolic names in rev must already be defined; see the _n and _N options for assigning names during checkin. If rev is $, ci determines the revision number from keyword values in the working file.
If rev begins with a period, then the default branch (normally the trunk) is prepended to it. If rev is a branch number followed by a period, then the latest revision on that branch is used.
If rev is a revision number, it must be higher than the latest one on the branch to which rev belongs, or must start a new branch.
If rev is a branch rather than a revision number, the new revision is appended to that branch. The level number is obtained by incrementing the tip revision number of that branch. If rev indicates a nonexistent branch, that branch is created with the initial revision numbered rev.1.
If rev is omitted, ci tries to derive the new revision number from the caller's last lock. If the caller has locked the tip revision of a branch, the new revision is appended to that branch. The new revision number is obtained by incrementing the tip revision number. If the caller locked a nontip revision, a new branch is started at that revision by incrementing the highest branch number at that revision. The default initial branch and level numbers are 1.
If rev is omitted and the caller has no lock, but owns the file and locking is not set to strict, then the revision is appended to the default branch. (Normally the trunk; see the _b option of rcs(1).)
Exception: On the trunk, revisions can be appended to the end, but not inserted.