SCN: Re: SCN's web front page
Randy Groves
randy at scn.org
Sun Sep 16 11:49:31 PDT 2001
Rod,
Please refrain from making comments about the operation of the system that
are misleading and incorrect.
'rwrap' is NOT required. It was suggested as a tool, to provide backup in
case of errors - NOT required.
There have been NO restrictions imposed, either programmatically nor by
policy that removes the ability to edit files with vi, pico, etc.
I have to agree that our FTP policies have been less that cohesive, but I
believe that those issues can be worked.
Please check your facts before making statements.
-randy
On Fri, 14 Sep 2001, Rod Clark wrote:
> Lee,
>
> > 2) the Operations Committee's criteria for posting information
>
> For posting updates to the home page, which is what we were
> talking about, these criteria include studying and understanding
> a pre-processor and post-processor for RCS that is non-standard
> and is not used on any other system anywhere - it was programmed
> by a member of the SCN Operations Committee. After that, you can
> brush up on 'man vi'. Using the Operations Committee's unique
> rwrap program is is the only way now that anyone can edit the
> home page.
>
> > 3) since regular text editing and FTP are no longer allowed by Ops
>
> Because of the above requirement, you can't simply use a
> regular text editor to edit the page. FTP is now impossible to
> use to update the page, even if you are one of the few people
> with group write permissions to do so. The output of 'man rwrap'
> is posted below, to show you how this interesting program works.
> Sorry for the mismatched formatting. Type 'man rwrap' at the
> Unix command line and the formatting will work right when used
> interactively on the screen.
>
>
> Rod Clark
>
> -----
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> NAME
>
> RWRAP - Wraps RCS processing around file processing
>
> SYNOPSIS
> rwrap [-v|-h]
>
> rwrap [options] _f_i_l_e
>
> rwrap [options] -ed _e_d_i_t_o_r _f_i_l_e
>
> rwrap [options] -cp _s_o_u_r_c_e_f_i_l_e _f_i_l_e
>
> rwrap [options] -cl _c_o_m_m_a_n_d _f_i_l_e [_m_o_r_e _f_i_l_e_s ...]
>
> rwrap [options] [-noop|-ante|-post] _f_i_l_e [_m_o_r_e _f_i_l_e_s ...]
>
> where
>
> _f_i_l_e is the file to modify (default: with 'vi').
>
> _e_d_i_t_o_r is the editor to use.
>
> _s_o_u_r_c_e_f_i_l_e is the file to copy from.
>
> _c_o_m_m_a_n_d can be any command, utility, or script.
>
> _o_p_t_i_o_n_s include:
> -_v_c, -_s_a_v_e, -_b_a_c_k_u_p, -_n_o_l_o_c_k, -_n_o_r_e_a_d_m_e,
> -_l, -_m "<_t_e_x_t>", -_w <_a_u_t_h_o_r>.
>
>
> PURPOSE
> rwrap "wraps" file modification within appropriate and
> mostly automatic RCS (Revision Control System) processing.
> Its purpose is to provide _s_a_f_e, _s_t_a_n_d_a_r_d, _a_n_d _c_o_n_s_i_s_t_e_n_t _u_s_e
> _o_f _R_C_S _a_c_r_o_s_s _t_h_e _o_r_g_a_n_i_z_a_t_i_o_n, with responses appropriate
> to various situations that may be encountered, without
> requiring the users to bother with the fine points of RCS or
> organizational preferred practices. rwrap has been made
> highly versatile and as simple as possible to encourage its
> use.
>
> rwrap is specifically designed for use on configuration
> files, and especially system configuration files in a
> multi-user environment. It has also been designed with
> rigorous attention to various possible situations and prob-
> lems, in order to be as robust and safe as possible. As a
> result it is significantly safer to do RCS with rwrap than
> to do it directly with the RCS commands. However, rwrap is
> not a total panacea; it does not overcome certain limita-
> tions and defects of RCS (see BUGS), nor does it attempt to
> handle every possible problem or situation.
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 1
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> Caution regarding inconsistent use of RCS: _i_n_c_o_n_s_i_s_t_e_n_t _u_s_e
> _o_f _R_C_S, _o_r _m_i_x_e_d _u_s_e _a_n_d _n_o_n-_u_s_e, _w_i_l_l _c_a_u_s_e _p_r_o_b_l_e_m_s. The
> solution is to use RCS consistently. Note that processes
> that are not even RCS-aware can be effectively made RCS-
> aware, and in a standard, consistent manner, by running them
> inside rwrap using various modes as described below.
>
> Note also that rwrap leaves the work file(s) read-only. (In
> RCS terms, the working file is left "checked-out unlocked".)
> Other processes may require certain files to be writeable
> ("locked"); see the "-l" option on how this can be handled.
>
>
> DESCRIPTION
> For changes in the latest version see CHANGES.
>
> When called with a single argument of either -v or -h (or
> several similar variants), rwrap returns, respectively, the
> _v_e_r_s_i_o_n number, or a synopsis of _u_s_a_g_e, and exits.
>
> In the simplest case, rwrap takes just one argument, the
> name of the file to be edited. The editor to use is taken
> from the shell variable $EDITOR; if that is not set, the
> default editor is vi.
>
> Or an editor can be explicitly specified on the command line
> using the '-ed <editor>' option.
>
> Or the changes can be made by copying them from another file
> using the '-cp <sourcefile>' option.
>
> Or the changes can be made by any arbitrary command, util-
> ity, or script by using the '-cl <command line>' option.
> (If arguments are included, the must be included inside
> quote marks with the command. This can also be done with
> the '-ed' option.) This is very powerful; it allows utili-
> ties such as vipw to be run from rwrap. Any arguments that
> are to be given to the command have to be enclosed in quota-
> tion marks with the command. E.g.: -cl "<command> <arg1>
> <arg2>" <file>.
>
> (The main difference between '-ed' and '-cl' is that the
> target file is included on the command line for the former,
> but not the latter. If the command used needs a filename on
> its command line, do it within quotes as described above.)
>
> The -noop mode ("no operation") does nothing except to
> pause; this provides an opportunity to "shell out"--that is,
> to use '^Z' to go to a shell--to do _a_n_y kind of processing
> desired, and then return (with 'fg') to rwrap to complete
> the processing.
>
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 2
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> The -ante mode performs all checks and RCS pre-processing,
> sets lock files, then exits. The -post mode completes the
> job by doing RCS post-processing and generally cleaning up.
> These two modes are for special cases, including cleaning up
> after a crashed session; they are not recommended for gen-
> eral use. Note that -post expects to find things just as
> -ante would have left them--it objects if it is misused.
> When these two modes are used an "A" or a "P" is appended at
> the end of the log entry to indicate the state of affairs.
>
> Options may include any, or none, of the following:
>
> -vc: display version number and continue.
>
> -save and -backup: (these are synonyms) save a copy of
> each file specified on the command line to a backup file
> before making any changes or doing any RCS processing.
> Backup files are in the same directory as the file, and have
> the same name, with a tilde ("~") and number appended.
> Numbering starts with one ("1"), and is incremented to avoid
> conflicting with any existing files. The full name of the
> backup file is reported to the user; the backup number alone
> is recorded in the log file. Backups are made automatically
> if a file has been changed since it was last archived
> (checked-in).
>
> Note that rwrap does not remove backup files.
>
> -l: leaves work file(s) checked-out "locked" (see RCS
> TERMS AND CONCEPTS) with write permission. (The default is
> "unlocked", read-only.) This is automatic if '/etc/passwd'
> or '/etc/group' are specified. Note that leaving an RCS
> lock on a file may required explict unlocking (with 'rcs -u
> <filename>') prior to running rwrap.
>
> -nolock: turns off the use of a lock file (see FILES).
> This is for use with utilities that set a lock file them-
> selves that conflicts with the style of lock file set by
> rwrap itself. Applies only to the first specified file.
>
> -noreadme: when wrap encounters a "README" file (see
> FILES), it normally displays it (up to 20 lines), and asks
> whether to continue. The intent is to respect the conven-
> tion that a README file has important information regarding
> the target file, and that based on such information the user
> might want to abort the operation. Where frequent exposure
> to unchanged information becomes tedious, the -noreadme
> option can be used. When specified, only the first line of
> README file is displayed. If the README file has not been
> changed in more than 65 days, rwrap continues without paus-
> ing. However, if the modification time is more recent than
> that rwrap aborts. This is to protect against blunders
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 3
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> resulting from unawareness of new information. Please be
> careful: use of -noreadme is an _i_m_p_l_i_c_i_t, _a_n_d _p_o_s_s_i_b_l_y
> _f_a_l_s_e, _a_s_s_u_m_p_t_i_o_n that the README file has no information of
> importance. Use of -noreadme is _n_o_t _r_e_c_o_m_m_e_n_d_e_d if you have
> not recently read the relevant README files.
>
> -m "<text>": corresponds to the similar option of ci.
> This applies only when rwrap is given more than one file
> name (see below). rwrap will use the supplied <text> (must
> be quoted if it contains spaces or shell meta-characters) as
> the log message when checking in the additional files.
> (Else it says "Changes consequent to changes to" and names
> the target file.) Note that (unlike ci) a space is required
> after the "-m".
>
> -w <name>: corresponds to the similar option of ci used
> to specify the author. This is effective only for
> superusers, and the only effect is to suppress the request
> to enter a valid login name. Note that (unlike ci) a space
> is required after the "-w".
>
> In all cases rwrap requires the name of at least one file to
> be processed. With some options rwrap now handles addi-
> tional file names ("<more files> ...") to which RCS process-
> ing will also be done.
>
> File names can be prefixed with relative or absolute paths;
> rwrap resolves all filenames to their absolute pathname.
> rwrap also understands the "tilde" ("~[<username>]" conven-
> tion.
>
> Note that several of rwrap's modes are built to "wrap" RCS
> processing around programs and processes that are ignorant
> of RCS. In particular, a protection-deficient process (pro-
> gram, utility, or script) can be run inside rwrap using the
> -cl option.
>
> For example: rwrap -nolock -cl prog rwfile would check out
> the file 'rwfile', then run 'prog' (which presumably modi-
> fies the file in some way), then check in the file. 'prog'
> sees a writeable file; it does not see RCS, nor (in this
> case) even a lock file.
>
> For more complex cases, perhaps where a process is not redu-
> cible to a script, use the -ante and -post modes. E.g.:
>
> rwrap -ante file1 file2 file3
> [complex and mystical file processing]
> rwrap -post file1 file2 file3
>
> would first do various checks and then anterior RCS process-
> ing. After the files had been processed, running rwrap in
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 4
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> -post mode would do the posterior RCS processing.
>
> In all modes a great deal of file checking is done to ensure
> proper processing. These include handling of _s_y_m_b_o_l_i_c
> _l_i_n_k_s, _h_a_r_d-_l_i_n_k_s, _n_o_n-_w_r_i_t_e_a_b_l_e files or directories,
> reporting any "_R_E_A_D_M_E" or "_l_o_c_k" files found, and setting
> lock files as appropriate::
>
>
> For any file name that is neither a regular file nor a
> symbolic link (such as _d_i_r_e_c_t_o_r_i_e_s or _d_e_v_i_c_e_s), or is
> not writeable by the user, rwrap aborts.
>
> If a "_h_a_r_d-_l_i_n_k" is found (i.e., a file with more than
> one inode linked to it), rwrap aborts. There is no
> alternative here: both co and ci break hard-links,
> resulting in separate and independent files. You can
> have your file with multiple hard-links (multiple
> names), or you can have your file in configuration con-
> trol. But, under RCS, you cannot have both. (Consider
> making one a symlink.)
>
> If a "_R_E_A_D_M_E" file (with a name in the form of
> <_t_a_r_g_e_t>._R_E_A_D_M_E) is found, and -noreadme has not been
> specified, rwrap displays the first twenty lines, and
> asks the user whether to continue, or not. The intent
> is to respect the convention that a README file has
> important information regarding the target file, and
> that based on such information the user might want to
> abort the operation.
>
> If a "_S_T_O_P" file (see FILES) is found, rwrap aborts.
> This is intended for cases where processing of a file
> is deemed inadvisable, especially where a user might
> not be attentive to polite admonishments in a README
> file.
>
> If a _l_o_c_k _f_i_l_e (with a name of the form <_t_a_r_g_e_t>._l_o_c_k
> is found, rwrap aborts. (Except in -post mode; see
> below for details.) This is to avoid conflicts with
> other users or processess that are (or were) accessing
> the file. The contents of the file are displayed;
> hopefully this contains information about who set the
> lock and when. The user is advised to resolve the con-
> flict, or to remove the (possibly stale) lock file.
>
> _S_y_m_b_o_l_i_c _l_i_n_k_s ("symlinks") are resolved to whatever
> they are linked to (after checking for README and lock
> files), and the file validation checks repeated for the
> new target. (The symlinks themselves are not under
> configuration control. This is because RCS fails to
> distinguish the symlink from what the symlink points
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 5
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> to; co and ci would destroy the symlink.)
>
> If the file does not yet exist, rwrap also checks that
> you have _w_r_i_t_e _a_c_c_e_s_s to the specified directory.
>
> _l_o_c_k _f_i_l_e_s (see FILES) are set at each symbolic link
> encountered, and for the fully resolved filename.
> (Unless '-nolock' is specifed--see above.)
>
>
> Once all of the supplied file names have been fully resolved
> and checked, rwrap will then check for:
>
>
> - a writeable RCS directory.
>
> - unarchived changes.
>
> - RCS locks.
>
>
> If any _u_n_a_r_c_h_i_v_e_d _c_h_a_n_g_e_s or _R_C_S _l_o_c_k_s are found rwrap
> queries the user for instructions.
>
> In -post mode: It is an error if the expected _w_o_r_k _f_i_l_e_s,
> _l_o_c_k _f_i_l_e_s, and _R_C_S _l_o_c_k_s are _n_o_t found, or if another user
> owns the RCS lock-- rwrap expects to find matters just as
> they would be left from -ante mode. The contents of any
> lock files found will be displayed, and the user asked if
> they are current, consistent, and what is expected. (I.e.,
> check that someone else has not set a lock file.) The check
> for unarchived changes is not made--such differences are
> expected.
>
> Otherwise: the user is asked how to handle any unarchived
> changes, and whether to break any RCS locks. (The presump-
> tion is that they are stale; it is up to the user--sigh--to
> detect and respond appropriately when they are not stale.)
>
>
> rwrap always puts the RCS archive file into an 'RCS' sub-
> directory below the directory of the target file. If the
> 'RCS' directory does not exist, rwrap will attempt to create
> it. If it can't, or if it fails, or if an existing RCS
> directory is not writeable, rwrap aborts.
>
> rwrap also warns if an RCS archive file exists in the same
> directory as the target. (This may indicate an earliar
> archive, or a failure of some kind). If the (possibly new)
> RCS directory does not have a copy of that archive file,
> rwrap will offer to move it.
>
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 6
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> rwrap creates a _l_o_c_k _f_i_l_e for each file being processed, and
> for each symbolic link that was encountered in resolving the
> supplied file name. These files contain the username of the
> rwrap process and the time. They will be removed when rwrap
> finishes.
>
> The appropriate RCS processing depends on the RCS status of
> the file. This is somewhat complex, but can be reduced to
> four cases:
>
>
> No archive file, no working file:
> No pre-processing; do an "initial check-in" of file after-
> wards.
>
>
> No archive file, but working file exists:
> Working file already exists, but has not yet been checked
> into RCS. rwrap notes this, and will do an initial check-
> in.
>
>
> Archive file exists, but not working file:
> File has been previously archived. Check out a clean
> copy.
>
>
> Both archive file and working file exist:
> File has been previously archived, but a working file has
> been checked out, possibly with an RCS lock, and possibly
> with outstanding changes. This is the interesting case.
>
> If the file is locked (see RCS TERMS AND CONCEPTS), rwrap
> will display who locked it (probably "root"!), and offers
> to break the lock. (Or it aborts.)
>
> If rcsdiff shows any differences from the last checked in
> revision, rwrap offers to display them. (This uses less.
> Enter q to quit.) The user then has a choice to save the
> changes, remove them, or quit. If the changes are saved,
> they will be checked in. The changes (in diff format)
> will also be stored in a "dump" file (see FILES).
>
> Note that the handling of unarchived changes is problemat-
> ical. On one hand, we need the documenation of what
> changes are made when and by whom. Especially by whom, so
> that any questions about the changes themselves, or of
> their legitimacy (!!), can be referred quickly and
> directly to their putative author. Therefore, by agreed
> upon policy, checking in of changes is required. Any
> changes not checked in are suspect. Even if they are not
> actually malevolent in intent, they are still corrosive of
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 7
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> proper administration.
>
> On the other hand, and especially during the transition
> from mostly non-conforming practice to conforming prac-
> tice, inconsistent use of RCS could result in loss of
> vital changes. Note that whether you save "bad" changes,
> or remove "good" changes, you can get into big trouble (or
> cause big problems) either way. The proper response
> depends on the circumstances. Be cautious, act prudently.
>
>
> (Policy note: In Operations we have decided that: if one
> person makes critical changes to file, but does not properly
> check them in, and another person does a co that removes
> those changes, whereupon something crashes, the _f_a_u_l_t _s_h_a_l_l
> _b_e _o_n _t_h_e _p_e_r_s_o_n _n_o_t _c_h_e_c_k_i_n_g-_i_n those changes. But it
> would be better to not screw-up in the first place, so
> please use rwrap.)
>
>
> After all the validation and preprocessing is done rwrap
> performs whatever process is appropriate to the mode--
> presumably modifying the specified files--and then asks
> whether to "Save" the changes (that is, to check them into
> the archive), or to "Undo" (as far as possible) all changes.
> In the latter case rwrap will delete any new files (that did
> not exist before). It then attempts to restore the initial
> working file from a backup copy (if any), or check out the
> last revision of a previously archived file. The default
> here is dependent on the exit code returned by the process
> that modified the file: if an error was reported the
> default is to Undo, else the the default is to Save. Note
> that various failure or abort terminations wil attempt to do
> an "Undo".
>
> Checked in changes are given the user's login name as the
> author. Superusers (uid 0) are asked at the beginning of
> the process for a valid non-superuser login name, unless it
> already supplied with the -w option or otherwise determined.
> Superusers are also asked at the end if they want to add a
> journal entry.
>
>
> OUTPUT
> The various RCS commands tend to be verbose. To make what
> is happening more comprehensible, rwrap inserts lines (gen-
> erally begining with "----" for clarity) to identify each
> stage of processing, and each file being processed. Lines
> beginning with ">" are requests for user input. Lines
> beginning with a star ("*") are error messages. When abort-
> ing rwrap will report the numeric codes of every problem it
> detected.
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 8
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> Note that other output, including error messages, may be
> returned by external programs (such as editors or scripts).
> Be careful to distinguish such output from rwrap's output.
>
>
> LOGGING
> Each session of rwrap that passes the initial syntax and
> environment checks is logged in the 'rwrap.log' file. This
> is in /var/log for all superuser's (providing a convenient
> record of files that have been modified by "root"), else in
> the user's home directory. The log record for each session
> includes a time stamp, and a list of each file specified.
> The files are listed by their resolved absolute pathnames.
> If the basename of this differs from what was specified on
> the command line, the latter is included within parentheses.
> If rwrap is run in -ante or -post mode an "A" or a "P",
> respectively, will be appended to the line.
>
> Additional records (using the same time stamp as the first
> record) may be added to indicate if unarchived changes
> ("Diffs") were found, or to record the backup number of any
> backup files. These are listed in the same order as the
> files they refer to. If rwrap fails or the user quits,
> another record will be added with the error code returned.
> (This only generally indicates the problem or problems
> encountered; the user is not relieved of recording any prob-
> lem codes returned.)
>
> For superusers: the user name to which the changes are being
> attributed is logged, and a record (with the login name of
> the superuser in square brackets) added to that user's log
> file.
>
>
> FILE OWNER AND GROUP
> One of the problems with RCS is that the original "owner"
> and "group" of the work and archive file are not preserved
> by the co, ci, or rcs commands. (Instead of modifying a
> file, the RCS commands create a new file to replace the old
> one.) rwrap now collects the uid and gid of each file, and
> attempts to restore them at the end of the session. (Actu-
> ally it collects the uid and gid of the archive file, or the
> work file if the archive file does not exist, and applies
> that to both the work and archive files.) Note that while a
> superuser can freely change the owner and group of any file,
> regular users can only change the group of a file they own
> to a group of which they are a member. So if you have
> write-access to a directory (and if you don't the RCS com-
> mands will fail), you can replace a file even if you are not
> a member of its group. But in that case you will not be
> able to restore the group id. (Some day rwrap may provide a
> warning when this is about to happen.)
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 9
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> Note also that in -post mode rwrap does not have knowledge
> of what the uid and gid may have been earlier: if you do
> something that changes either, that's what will be pro-
> pagated.
>
> Backup copies of the a work file will generally have the
> original owner and group attributes. (This uses the '-p'
> ["preserve"] option of the cp command.) But if rwrap tries
> to restore a work file (such as with the "Undo" option) it
> will attempt to give it the owner and group attributes of
> the archive file.
>
>
> CHANGES
> A new option, "-save", can be specified to save (make back-
> ups) all of the files specified on the command line at the
> outset. (See FILES). This is done automatically for any
> file that has been changed since it was last archived
> (checked in).
>
> rwrap now attempts to restore the original "group" of the
> files for all users (not just the superuser), and also the
> "owner" when run by the superuser. See FILE OWNER AND
> GROUP, above.
>
>
> RCS TERMS AND CONCEPTS
> rwrap is essentially nothing more than a means to an end,
> that end being the application of RCS (Revision Control Sys-
> tem) commands in a suitable manner. While rwrap tries to
> shield the user from various complexities of using RCS, it
> is nonetheless highly advantageous to understand the follow-
> ing RCS terms and concepts.
>
> The _w_o_r_k _f_i_l_e is the file (files) that is being worked on,
> whose revisions are being archived. The _a_r_c_h_i_v_e _f_i_l_e is
> where RCS keeps the information it needs to track the revi-
> sions to the work file. Normally the archive file is of
> significance to the user only to the extent of whether it
> exists or not.
>
> _C_h_e_c_k-_i_n is the process of _a_r_c_h_i_v_i_n_g the current _r_e_v_i_s_i_o_n of
> the work file so that it can be accessed in the future.
> (Normally with the ci command.) _C_h_e_c_k-_o_u_t is the process of
> restoring a work file to the state of some previously
> archived revision. (Normally with the co command, but some
> usages of ci also do a check-out.) In software development
> environments (and the default behavior of RCS) work files
> are often removed when they are checked-in, and checked-out
> only when needed. On the other hand, configuration files
> (for which rwrap is intended) generally should not be
> removed; rwrap therefore leaves the working file "checked-
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 10
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> out".
>
> RCS implements _l_o_c_k_s to indicate when someone has been given
> access for modifying the work file (and the file given write
> permission). (This is to be distinguished from a _l_o_c_k _f_i_l_e,
> to be discussed shortly.) rwrap handles getting a lock. For
> another user to obtain write-access to the file (through
> RCS), either the first user must relinquish the lock (such
> as by checking-in the file), or the other user must _b_r_e_a_k
> _t_h_e _l_o_c_k. rwrap handles all the details of doing this, but
> the decision to break a lock, and the responsibility for any
> consequences, necessarily lie with the user.
>
> For more information about RCS see the man pages for rcsin-
> tro(1), ci(1), co(1), and rcs(1).
>
> Note that _R_C_S _l_o_c_k_s (described above) are to be dis-
> tinguished from the _l_o_c_k _f_i_l_e_s that rwrap uses. The former
> are internal to, and meaningful only in the context of, RCS.
> The latter is a general convention for indicating to other
> processes and users that a file is being accessed, and sub-
> ject to modification. rwrap respects "lock" files, sets
> them, and removes them when done. See FILES.
>
>
> RCS PARAMETERS
> As rwrap is designed specifically to do configuration con-
> trol on configuration files, it always leaves a copy of the
> "working file" checked out. Generally it leaves the working
> file "unlocked"--that is, read-only--to deter changing it
> outside of RCS, and (hopefully) as a gentle hint that the
> file is under configuration control. It will leave the
> specified file(s) "locked", with read-write permissions, if
> the '-l' option is specified, or if '/etc/passwd' or
> '/etc/group' are specified.
>
> Check-ins always include the user's login name (or a valid
> login name supplied by superuers) as author (ci's -w
> option). This identifies who is responsible for the
> changes, and to whom to ask regarding the changes, their
> legitimacy, or the validity of the attribution.
>
> Check-in's are always "forced"; that is, the file is always
> checked in (if "Saved") as a new revision even if there were
> no changes. This is so multiple files handled as a set will
> show when changes were made to any file in the set, and to
> simplify user interaction.
>
> Check-out's are also forced, again to simplify user interac-
> tion.
>
> Note that the user's RCSINIT environmental variable, if set,
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 11
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> will affect the RCS programs used by rwrap, and could cause
> rwrap to fail.
>
>
> RETURN CODES
> rwrap returns 0 if no errors are detected (but see BUGS), or
> an integer indicating where it aborted or the user quit.
> When processing more than one file it will check all of the
> files specified, but generally will find only one problem or
> error per file. Before exiting it will display the numeric
> codes of all problems detected. The last two digits indi-
> cate the specific error, and any preceeding digits indicate
> which file (in the order specified on the command line).
> The return code is generally the first error code found.
>
>
> FILES
> A given file name (with optional pathname, relative or abso-
> lute) is resolved through any symbolic links to identify the
> actual target file. rwrap then references:
>
> _t_a_r_g_e_t - the file to be changed (after resolving any
> symlinks).
>
> _t_a_r_g_e_t,v - possibly an old archive file.
>
> RCS - subdirectory for RCS archive files.
>
> RCS/_t_a_r_g_e_t,v - the RCS archive file for _t_a_r_g_e_t.
>
> _t_a_r_g_e_t.README - has information pertaining to _t_a_r_g_e_t.
> _s_y_m_l_i_n_k.README - same, but relative to any symlink files
> found; could be in a different directory. Whenever rwrap
> finds a symlink it looks for an associated README file.
>
> _t_a_r_g_e_t.lock - the "lock" file.
>
> _t_a_r_g_e_t~_n_n - general form of backup file(s).
>
> _t_a_r_g_e_t.xx - temporarily holds unrecorded changes.
>
> _t_a_r_g_e_t.XX - accumulated unrecorded changes.
>
> _t_a_r_g_e_t.STOP - the "STOP" file.
>
> These preceeding files are relative to the directory con-
> taining _t_a_r_g_e_t, except there may be additional README or
> lock files relative to any symbolic links found.
>
> /$HOME/rwrap.log - log file.
>
> /var/log/rwrap.log - log file for superusers.
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 12
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> REQUIRES
> rwrap is now a unitary Perl script, and requires no other
> programs except for the RCS programs (rlog, rcs, rcsdiff,
> co, and ci), and other standard Unix programs.
>
>
>
> SEE ALSO
> See also: rcsintro(1), ci(1), co(1), rcsdiff(1), rlog(1),
> and rcs(1).
>
>
> BUGS, DEFECTS, AND UNRESOLVED ISSUES
> There are still some odd problems when used as root in
> SunOS.
>
> There may be problems with specific terminal (stty) set-
> tings.
>
> Can't protect against mishaps where RCS is used incon-
> sistently.
>
> Unable to entirely transcend the deficiencies of RCS, such
> as destroying symbolic links, hard links, and existing file
> ownership.
>
> Maintaining owner and group attributes is only partly
> solved. There should be some way of finessing RCS to
> preserve the owner and group of an existing file; perhaps by
> substituting another file.
>
> Does not distinguish between an RCS lock on the current
> revision of a file, and an RCS lock on some other revision
> or branch.
>
> Lock files can't protect against other processes or users
> that don't respect lock files, or come in through a dif-
> ferent symlink.
>
> Ability to verify the true identity of a superuser is lim-
> ited.
>
> Unable to remove all sources of user error.
>
> There are undoubtably some subtle improvements to made in
> regards of permissions.
>
> Too much information displayed on the screen. Wait--that's
> a feature!
>
>
>
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 13
>
>
>
>
>
>
> RWRAP(1) USER COMMANDS RWRAP(1)
>
>
>
> AUTHOR
> Written by "JJ". Send comments to jj at scn.org.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sun Release 4.1 Last change: 21 March 2001 14
>
>
>
>
> * * * * * * * * * * * * * * From the Listowner * * * * * * * * * * * *
> . To unsubscribe from this list, send a message to:
> majordomo at scn.org In the body of the message, type:
> unsubscribe scn
> ==== Messages posted on this list are also available on the web at: ====
> * * * * * * * http://www.scn.org/volunteers/scn-l/ * * * * * * *
>
* * * * * * * * * * * * * * From the Listowner * * * * * * * * * * * *
. To unsubscribe from this list, send a message to:
majordomo at scn.org In the body of the message, type:
unsubscribe scn
==== Messages posted on this list are also available on the web at: ====
* * * * * * * http://www.scn.org/volunteers/scn-l/ * * * * * * *
More information about the scn
mailing list