SCN: Re: SCN's web front page
Rod Clark
bb615 at scn.org
Fri Sep 14 18:47:58 PDT 2001
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/ * * * * * * *
More information about the scn
mailing list