home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 5 Edit
/
05-Edit.zip
/
elvis184.zip
/
os2
/
elvprsv.doc
< prev
next >
Wrap
Text File
|
1994-01-17
|
3KB
|
133 lines
NAME
elvprsv - Preserve the the modified version of a file
after a crash.
SYNOPSIS
elvprsv ["-why elvis died"] /tmp/filename...
elvprsv -R /tmp/filename...
DESCRIPTION
elvprsv preserves your edited text after elvis dies. The
text can be recovered later, via the elvprsv program.
For UNIX-like systems, you should never need to run this
program from the command line. It is run automatically
when elvis is about to die, and it should be run (via
/etc/rc) when the computer is booted. THAT'S ALL!
For non-UNIX systems such as MS-DOS or VMS, you can either
use elvprsv the same way as under UNIX systems (by running
it from your AUTOEXEC.BAT file), or you can run it sepa-
rately with the "-R" flag to recover the files in one
step.
If you're editing a file when elvis dies (due to a bug,
system crash, power failure, etc.) then elvprsv will pre-
serve the most recent version of your text. The preserved
text is stored in a special directory; it does NOT over-
write your text file automatically. (If the preservation
directory hasn't been set up correctly, then elvprsv will
simply send you a mail message descrining how to manually
run elvprsv.)
elvprsv will send mail to any user whose work it pre-
serves, if your operating system normally supports mail.
FILES
/tmp/elv*
The temporary file that elvis was using when it
died.
/usr/preserve/p*
The text that is preserved by elvprsv.
/usr/preserve/Index
A text file which lists the names of all preserved
files, and the names of the /usr/preserve/p* files
which contain their preserved text.
BUGS
Due to the permissions on the /usr/preserve directory, on
UNIX systems elvprsv must be run as superuser. This is
accomplished by making the elvprsv executable be owned by
"root" and turning on its "set user id" bit.
1
ELVPRSV(1) ELVPRSV(1)
If you're editing a nameless buffer when elvis dies, then
elvprsv will pretend that the file was named "foo".
AUTHOR
Steve Kirkendall
kirkenda@cs.pdx.edu
2