Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

elvprsv(8) [minix man page]

ELVPRSV(8)						      System Manager's Manual							ELVPRSV(8)

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, 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 separately 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 preserve the most recent ver- sion of your text. The preserved text is stored in a special directory; it does NOT overwrite your text file automatically. elvprsv will send mail to any user whose work it preserves, 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. 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 ELVPRSV(8)

Check Out this Related Man Page

REF(1)							      General Commands Manual							    REF(1)

NAME
ref - Display a C function header SYNOPSIS
ref [-t] [-c class]... [-f file]... tag DESCRIPTION
ref quickly locates and displays the header of a function. To do this, ref looks in the "tags" file for the line that describes the func- tion, and then scans the source file for the function. When it locates the function, it displays an introductory comment (if there is one), the function's declaration, and the declarations of all arguments. SEARCH METHOD
ref uses a fairly sophisticated tag look-up algorithm. If you supply a filename via -f file, then elvis first scans the tags file for a static tag from that file. This search is limited to the tags file in the current directory. If you supply a classname via -c class, then elvis searches for a tag from that class. This search is not limited to the current direc- tory; You can supply a list of directories in the environment variable TAGPATH, and ref will search through the "tags" file in each direc- tory until it finds a tag in the desired class. If that fails, ref will then try to look up an ordinary global tag. This search checks all of the directories listed in TAGPATH, too. If you've given the -t flag, then ref will simply output the tag line that it found, and then exit. Without -t, though, ref will search for the tag line. It will try to open the source file, which should be in the same directory as the tags file where the tag was discov- ered. If the source file doesn't exist, or is unreadable, then ref will try to open a file called "refs" in that directory. Either way, ref will try to locate the tag, and display whatever it finds. INTERACTION WITH ELVIS
ref is used by elvis' shift-K command. If the cursor is located on a word such as "splat", in the file "foo.c", then elvis will invoke ref with the command "ref -f foo.c splat". If elvis has been compiled with the -DEXTERNAL_TAGS flag, then elvis will use ref to scan the tags files. This is slower than the built-in tag searching, but it allows elvis to access the more sophisticated tag lookup provided by ref. Other than that, external tags should act exactly like internal tags. OPTIONS
-t Output tag info, instead of the function header. -f file The tag might be a static function in file. You can use several -f flags to have ref consider static tags from more than one file. -c class The tag might be a member of class class. You can use several -c flags to have ref consider tags from more than one class. FILES
tags List of function names and their locations, generated by ctags. refs Function headers extracted from source files (optional). ENVIRONMENT
TAGPATH List of directories to be searched. The elements in the list are separated by either semicolons (for MS-DOS, Atari TOS, and Amiga- Dos), or by colons (every other operating system). For each operating system, ref has a built-in default which is probably ade- quate. NOTES
You might want to generate a "tags" file the directory that contains the source code for standard C library on your system. If licensing restrictions prevent you from making the library source readable by everybody, then you can have ctags generate a "refs" file, and make "refs" readable by everybody. If your system doesn't come with the library source code, then perhaps you can produce something workable from the lint libraries. SEE ALSO
elvis(1), ctags(1) AUTHOR
Steve Kirkendall kirkenda@cs.pdx.edu REF(1)
Man Page