# @(#)README 8.25 (Berkeley) 8/19/96
Nvi uses the GNU autoconf program for configuration and compilation. You
should enter:
configure
make
and nvi will configure the system and build one or two binaries: nvi and
tknvi. You can use any path to the configure script, e.g., to build for
an x86 architecture, I suggest that you do:
mkdir build.x86
cd build.x86
../build/configure
make
There are options that you can specify to the configure command. See
the next section for a description of these options.
If you want to rebuild or reconfigure nvi, for example, because you change
your mind as to the curses library that you want to use, create a new
directory and reconfigure it using "configure" and whatever options you
choose, don't try to selectively edit the files.
By default, nvi is installed as "vi", with hard links to "ex" and "view".
To install them using different names, use the configure program options.
For example, to install them as "nvi", "nex" and "nview", use:
configure --program-prefix=n
See the section below on installation for details.
Note, if you're building nvi on a LynxOS system, you should read the
README.LynxOS file in this directory for additional build instructions
that are specific to that operating system.
If you have trouble with this procedure, send email to the addresses
listed in ../README. In that email, please provide a complete script
of the output for all of the above commands that you entered.
=-=-=-=-=-=-=
NVI'S OPTIONS TO THE CONFIGURE PROGRAM
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There are many options that you can enter to the configuration program.
To see a complete list of the options, enter "configure --help". Only
a few of them are nvi specific. These options are as follows:
--disable-curses DON'T use the nvi-provided curses routines.
--disable-db DON'T use the nvi-provided DB routines.
--disable-re DON'T use the nvi-provided RE routines.
--enable-debug Build a debugging version.
--enable-perlinterp Include a Perl interpreter in vi.
--enable-tclinterp Include a Tk/Tcl interpreter in vi.
--enable-tknvi Build a Tk/Tcl front-end for vi.
disable-curses:
By default, nvi loads its own implementation of the curses
routines (which are a stripped-down version of the 4.4BSD curses
library). If you have your own curses library implementation and
you want to use it instead, enter:
--disable-curses
as an argument to configure, and the curses routines will be taken
from whatever libraries you load. Note: System V based curses
implementations are usually broken. See the last section of this
README for further information about nvi and the curses library.
disable-db:
By default, nvi loads its own versions of the Berkeley DB routines
(which are a stripped-down version of DB 1.85). If you have your
own version of the Berkeley DB routines and you want to use them
instead, enter:
--disable-db
as an argument to configure, and the DB routines will be taken
from whatever libraries you load. Make sure that the DB routines
you use are at least version 1.85 or later.
disable-re:
By default, nvi loads its own versions of the POSIX 1003.2 Regular
Expression routines (which are Henry Spencer's implementation).
If your C library contains an implementation of the POSIX 1003.2
RE routines (note, this is NOT the same as the historic UNIX RE
routines), and you want to use them instead, enter:
--disable-re
as an argument to configure, and the RE routines will be taken
from whatever libraries you load. Please ensure that your RE
routines implement Henry Spencer's extensions for doing vi-style
"word" searches.
enable-debug:
If you want to build nvi with no optimization (i.e. without -O
as a compiler flag), with -g as a compiler flag, and with DEBUG
defined during compilation, enter:
--enable-debug
as an argument to configure.
enable-perlinterp:
If you have the Perl 5 libraries and you want to compile in the
Perl interpreter, enter:
--enable-perlinterp
as an argument to configure. (Note: this is NOT possible with
Perl 4, or even with Perl 5 versions earlier than 5.002.)
enable-tclinterp:
If you have the Tk/Tcl libraries and you want to compile in the
Tcl/Tk interpreter, enter:
--enable-tclinterp
as an argument to configure. If your Tk/Tcl include files and
libraries aren't in the standard library and include locations,
see the next section of this README file for more information.
enable-tknvi:
If you have the Tk/Tcl libraries and you want to build the Tcl/Tk
nvi front-end, enter:
--enable-tknvi
as an argument to configure. If your Tk/Tcl include files and
libraries aren't in the standard library and include locations,
see the next section of this README file for more information.
=-=-=-=-=-=-=
ADDING OR CHANGING COMPILERS, OR COMPILE OR LOAD LINE FLAGS
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you want to use a specific compiler, specify the CC environment
variable before running configure. For example:
env CC=gcc configure
Using anything other than the native compiler will almost certainly
mean that you'll want to check the compile and load line flags, too.
If you want to specify additional load line flags, specify the ADDLDFLAGS
environment variable before running configure. For example:
env ADDLDFLAGS="-Q" configure
would specify the -Q flag in the load line when the nvi programs are
loaded.
If you don't want configure to use the default load line flags for the
system, specify the LDFLAGS environment variable before running configure.
For example:
env LDFLAGS="-32" configure
will cause configure to set the load line flags to "-32", and not set
them based on the current system.
If you want to specify additional compile line flags, specify the
ADDCPPFLAGS environment variable before running configure. For example:
env ADDCPPFLAGS="-I../foo" configure
would cause the compiler to be passed the -I../foo flag when compiling
test programs during configuration as well as when building nvi object
files.
If you don't want configure to use the default compile line flags for the
system, specify the CPPFLAGS environment variable before running configure.
For example:
env CPPFLAGS="-I.." configure
will cause configure to use "-I.." as the compile line flags instead of
the default values.
=-=-=-=-=-=-=
ADDING LIBRARIES AND INCLUDE FILES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If the Tk/Tcl or any other include files or libraries are in non-standard
places on your system, you will need to specify the directory path where
they can be found.
If you want to specify additional library paths, set the ADDLIBS environment
variable before running configure. For example:
env ADDLIBS="-L/a/b -L/e/f -ldb" configure
would specify two additional directories to search for libraries, /a/b
and /e/f, and one additional library to load, "db".
If you want to specify additional include paths, specify the ADDCPPFLAGS
environment variable before running configure. For example:
env ADDCPPFLAGS="-I/usr/local/include" LIBS="-ldb" configure
would search /usr/local/include for include files, as well as load the db
library as described above.
As a final example, let's say that you've downloaded ncurses from the net
and you've built it in a directory named ncurses which is at the same
level in the filesystem hierarchy as nvi. You would enter something like:
env ADDCPPFLAGS="-I../../ncurses/include" \
ADDLIBS="-L../../ncurses/libraries" configure
to cause nvi to look for the curses include files and the curses library
in the ncurses environment.
Notes:
Make sure that you prepend -L to any library directory names, and
that you prepend -I to any include file directory names! Also,
make sure that you quote the paths as shown above, i.e. with
single or double quotes around the values you're specifying for
ADDCPPFLAGS and ADDLIBS.
=-=-=-=-=-=
You should NOT need to add any libraries or include files to load
the Perl5 interpreter. The configure script will obtain that
information directly from the Perl5 program. This means that the
configure script must be able to find perl in its path. It looks
for "perl5" first, and then "perl". If you're building a Perl
interpreter and neither is found, it's a fatal error.
=-=-=-=-=-=
You do not need to specify additional libraries to load Tk/Tcl,
Perl or curses, as the nvi configuration script adds the
appropriate libraries to the load line whenever you specify
--enable-tknvi or other Perl or Tk/Tcl related option, or build
the Tk/Tcl or curses version of nvi. The library names that are
automatically loaded are as follows:
for Perl: -lperl
for Tk/Tcl: -ltk -ltcl -lm
for curses: -lcurses
In addition, the configure script loads:
... the X libraries when loading the Tk/Tcl libraries,
if they exist.
... the -ltermcap or -ltermlib libraries when loading
any curses library, if they exist.
=-=-=-=-=-=
The env command is available on most systems, and simply sets one
or more environment variables before running a command. If the
env command is not available to you, you can set the environment
variables in your shell before running configure. For example,
in sh or ksh, you could do:
ADDLIBS="-L/a/b -L/e/f -ldb" configure
and in csh or tcsh, you could do:
setenv ADDLIBS "-L/a/b -L/e/f -ldb"
configure
See your shell manual page for further information.
=-=-=-=-=-=-=
INSTALLING NVI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Nvi installs the following files into the following locations, with
the following default values:
Variables: Default value:
prefix /usr/local
exec_prefix $(prefix)
bindir $(prefix)/bin
datadir $(prefix)/share
mandir $(prefix)/man
File(s): Default location
----------------------------------------
vi $(bindir)/vi
vi.1 $(mandir)/man1/vi.1
vi.0 $(mandir)/cat1/vi.0
Perl5 scripts $(datadir)/vi/perl/
Tcl scripts $(datadir)/vi/tcl/
Message Catalogs $(datadir)/vi/catalog/
Notes:
There are two hard links to the vi program, named ex and view.
Similarly, there are two hard links to the unformatted vi manual
page, named ex.1 and view.1, and two hard links to the formatted
manual page, named ex.0 and view.0. These links are created when
the program and man pages are installed.
If you want to install vi, ex, view and the man pages as nvi, nex,
nview, use the configure option --program-prefix=n. Other, more
complex transformations are possible -- use configure --help to
see more options.
To move the entire installation tree somewhere besides /usr/local,
change the value of both "exec_prefix" and "prefix". To move the
binaries to a different place, change the value of "bindir".
Similarly, to put the datafiles (the message catalogs, Perl5 and
Tcl scripts) or the man pages in a different place, change the
value of "datadir" or "mandir". These values can be changed as
part of configuration:
configure --exec_prefix=/usr/contrib --prefix=/usr/share
or when doing the install itself:
make exec_prefix=/usr/contrib prefix=/usr/contrib install
The datafile directory (e.g., /usr/local/share/vi by default) is
completely removed and then recreated as part of the installation
process.
=-=-=-=-=-=-=
NVI AND THE CURSES LIBRARY
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The major portability problem for nvi is selecting a curses library.
Unfortunately, it is common to find broken versions of curses -- the
original System V curses was broken, resulting in all vendors whose
implementations are derived from System V having broken implementations
in turn.
For this reason, BY DEFAULT, nvi uses the stripped-down curses library
that's included in its distribution. Of course, it would be preferable
to use the vendor's curses library, or one of the newer implementations
of curses, e.g., ncurses.
To use the vendor's curses library, specify the:
--disable-curses
argument to the configure command. If you use the vendor's or other
curses library, and you see any of the following symptoms:
+ Core dumps in curses routines.
+ Missing routines when compiling.
+ Repainting the wrong characters on the screen.
+ Displaying inverse video in the wrong places.
+ Failure to reset your terminal to the correct modes on exit.
you have a broken curses implementation, and you should reconfigure nvi
to use another curses library or the curses library provided with nvi.
There are two alternative sources for curses libraries:
#1: Compile the 4BSD curses library from any of the recent BSD
releases: FreeBSD, NetBSD or 4.4BSD-Lite release 2. These
libraries should be able to support nvi.
#2: Retrieve and build the ncurses library. This library is not
recommended unreservedly, at least for now, for two reasons.
First, it can't be built on any system where the compiler
doesn't support function prototypes. Second, it currently has
a few bugs in its support for nvi. It mostly works, but it's
still not quite right.
One final note. If you see the following symptoms:
+ Line-by-line screen repainting instead of scrolling.
it usually means that your termcap or terminfo information is insufficient
for the terminal.
README.LynxOS ============= Written by Ronald F. Guilmette <rfg@monkeys.com> Last modified Wed Aug 14 23:10:07 PDT 1996 ------------------------------------------ 0. Introduction --------------- This file describes how to build and install the Berkeley `nvi' editor for the LynxOS 2.4.0 operating system. LynxOS 2.4.0 is available for a variety of different hardware platforms, in particular, x86, m680x0, Sparc, and PowerPC. I have successfully built nvi on all four of these flavors of LynxOS by following the procedures given in this file. Note that these procedures may not work on versions of LynxOS prior to 2.4.0. (As I understand it, a good deal of work went into making the 2.4.0 release more POSIX-compliant, and I have no idea what build glitches, if any, you might run into if you try to build nvi on a pre-2.4.0 version of LynxOS.) There are basically four steps to configuring, building, and installing nvi on LynxOS, namely: 1. Get setup to use the proper C compiler. 2. Replace your installed `tr' program. 3. Fix your system include files. 4. Do a normal configure, build, and install of nvi. These steps are described in separate sections below. 1. Get Setup to Use the Proper C Compiler ------------------------------------------ The most important step when building nvi on LynxOS is your selection of a C compiler to use during the build. DO NOT try to use either the /bin/cc or the /bin/gcc compiler (i.e. GCC version 1.xx) to build nvi. These two compilers are ancient, crusty, buggy, and should probably not be used for anything. Rather than using either of these two C compilers, I strongly advise you to use the more up-to-date version of the GNU C compiler which is distributed with LynxOS. For LynxOS 2.4.0 on x86 systems, the path to the newer gcc is located in: /cygnus/94q4-lynxos-x86/bin For LynxOS 2.4.0 on m680x0 systems, the path to the newer gcc is in: /cygnus/94q4-lynxos-68k/bin For LynxOS 2.4.0 on Sparc systems, the path to the newer gcc is in: /cygnus/94q4-lynxos-usparc/bin For LynxOS 2.4.0 on PowerPC systems, the path to the newer gcc is in: /cygnus/95q2-lynxos-ppc/bin It is imperative that you setup your $PATH environment variable (*before* you do the configure step for nvi) so that the more up-to-date version of the GNU C compiler will appear in your $PATH before the /bin/cc or /bin/gcc compilers (if present). If you fail to do this, your attempts to build nvi will most likely fail. To make absolutely sure that you will be configuring and building nvi with the proper C compiler (i.e. the most up-to-date GNU C compiler on your system) you should add the directory name listed above for your specific system type to your $PATH setting in your $HOME/.profile file. (For csh/tcsh users, you will instead want to add the relevant directory name to the setting of your $path variable in your ~/.cshrc file.) Once you have added the proper direc- tory name (from the list given above) to your $HOME/.profile file (or to your ~/.cshrc file, if you are using csh or tcsh) you should log out completely and then log back into the system just to make sure your new $PATH/$path setting takes effect properly. When you finish making this adjustment to your $PATH (or $path), the most up-to-date version of gcc on your system should be available to you as the first `gcc' program on your $PATH. You should verify that this is indeed the case simply by typing `gcc -v' and then checking the version number reported by the compiler. It should say either "2.6-94q4" or (on PowerPC systems) it should say "2.6-95q2". If you don't get these results, try again to set your $PATH (or $path) until you do. You won't be able to build nvi until you are properly setup to use gcc version 2.6 or later. Performing the steps shown above will insure that your subsequent configura- tion and build steps for nvi will make use of the most up-to-date version of gcc that was shipped with your Lynx operating system. (Note that the versions of gcc which are currently shipping with LynxOS 2.4.0 are also somewhat out- of-date themselves, but they are still quite a bit newer and more bug-free and ANSI conformant that those other two C compilers which also currently ship with LynxOS.) (Note: At present, LynxOS version 2.4.0 is the latest officially released version of LynxOS, and all of the above information is accurate and correct for LynxOS 2.4.0 as of the time of this writing. However it is rumored that future releases of LynxOS may provide a still newer version of gcc, and that it may be located in the /usr/bin directory. Thus, if you are building nvi for some LynxOS version later than 2.4.0, you may wish to check and see if your system has a program called /usr/bin/gcc, and use that version of gcc, if available, rather than the one suggested above.) 2. Replace Your Installed `tr' Program --------------------------------------- The `tr' program which comes bundled with LynxOS 2.4.0 (as /bin/tr) has a somewhat obscure bug which just happens to be tickled by almost all GNU `autoconf' generated `configure' scripts (including the one that nowadays comes bundled with nvi). Using the stock /bin/tr program on LynxOS when executing such `configure' scripts _will_ cause these scripts to malfunction in various ways. It is therefore imperative that you replace your LynxOS /bin/tr program with a properly working version of the `tr' command _before_ you even try to configure nvi. (You can tell if your `tr' program has the bug by executng the command "echo ab- | tr ab- ABC". If this yields the string "Ab-" then you have the bug. If it yields "ABC" then you don't.) You can obtain sources for a working version of the `tr' command as part of the GNU `textutils' package (the latest version of which, at the time of this writing, is 1.19). The GNU textutils package is available for downloading from prep.ai.mit.edu in the pub/gnu directory. Look for the file named textutils-1.19.tar.gz, or an even more recent version of textutils, if one is available. Fetch it, gunzip it, untar it, and follow the directions in the INSTALL file included in the tar file to build and install the entire textutils set of utility programs (which includes a working `tr' program). Then just make sure that the GNU version of `tr' appears on your $PATH _before_ the LynxOS version of `tr' (i.e. /bin/tr). Be sure to do this step _before_ you start to configure nvi. When building the textutils set of programs, I suggest that you use the most up-to-date C compiler available on your system (as described above). Also, note that it will be important for you to AVOID using the -O (optimize) compiler option when building the GNU textutils package, even if you are using the most up-to-date version of gcc which shipped with your system. If you try to use -O when building the textutils package on an x86 with the Cygnus 94q4 C compiler, you will end up with a `tr' program which will malfunction even worse than the one you are trying to replace! If you use -O when building the textutils package on LynxOS on the PowerPC (using the Cygnus 95q2 C compiler) you will just get yourself a compiler crash. So just don't use -O when building textutils. You can avoid using -O by in- voking make in the textutils directory as follows: make CFLAGS="-g" (Note: At present, LynxOS version 2.4.0 is the latest officially released version of LynxOS, and all of the above information is accurate and correct for LynxOS 2.4.0 as of the time of this writing. However it is rumored that the bug in the /bin/tr program will be fixed in future releases of LynxOS, so if you have a version of LynxOS later than 2.4.0, you may wish to check and see if your /bin/tr program even has the problematic bug before bothering with all of this.) 3. Fix Your System Include Files --------------------------------- If you are building nvi on a PowerPC system, it is also important that you apply the patches given at the end of this file to your /usr/include files. (Note that you will have to be root in order to do this.) Two of the patches included below fix a pair of serious bugs in the /usr/include/stdarg.h file on the PowerPC, and you really _do_ want to have these bugs fixed anyway, because without these fixes, anything that you compile which uses <stdarg.h> will very likely malfunction at run-time. Regardless of which LynxOS platform you are using (i.e. x86, PowerPC, Sparc, or m680x0) you may want to apply all of the system include files patches that are included below anyway. Doing so will clean up a few minor problems with the relevant system include files (i.e. <stdarg.h>, <ioctl.h>, and <wait.h>) and this step will also prevent a few warnings which you would otherwise get during the build of nvi. You can apply all of the patches given at the end of this file simply by doing the following: su root cd /usr/include /bin/patch < this-file Where `this-file' is the actual full pathname of the file you are now reading, wherever it may reside on your own system. (Note: At present, LynxOS version 2.4.0 is the latest officially released version of LynxOS, and all of the above information is accurate and correct for LynxOS 2.4.0 as of the time of this writing. However it is rumored that future releases of LynxOS may incorporate some or all of the important system include file fixes provided below. Thus, if you are building nvi for some LynxOS version later than 2.4.0, you should probably go ahead and try to apply the patches given below to your system include files, and then just don't worry about it if these patches seem to have already been applied.) 4. A Brief Note about Sendmail ------------------------------- I should mention also that LynxOS does not normally ship with the `sendmail' mail transfer program installed, either under /usr/lib/ or anywhere else for that matter. This isn't really a big problem, but nvi normally wants and expects to have a sendmail program available so that it can send users notifi- cations (by mail) whenever a partially edited file is preserved by the editor in response to a sudden system crash, a sudden system shutdown, or an unexpect- ed serial-line hangup. You can configure and build nvi without any sendmail program installed on your system, but you will get warnings about its absence when you are doing the initial configure step prior to actually building nvi. If you want to have a fully-functional nvi which does send out notification messages (by mail) whenever partially edited files are preserved during a serial line hangup or system crash, then you should get the BSD sendmail sources (via ftp from ftp.cs.berkeley.edu), build and install sendmail, and then reconfigure, rebuild, and reinstall nvi. Please contact me at the E-mail address below if you experience any problems in building or using nvi on LynxOS. I make no guarrantees, but I may be willing to try to help. Ron Guilmette Roseville, California <rfg@monkeys.com> August 14, 1996 cut here for LynxOS 2.4.0 system include files patches ----------------------------------------------------------------------------- *** wait.h Fri Apr 26 10:02:45 1996 --- wait.h Sun May 19 05:36:50 1996 *************** *** 94,104 **** /* Function prototypes */ #ifndef __LYNXOS - #ifdef _POSIX_SOURCE extern pid_t wait _AP((int *)); extern pid_t waitpid _AP((pid_t, int *, int)); ! #else ! extern int wait _AP((union wait *)); ! extern int waitpid _AP((int, union wait *, int)); ! extern int wait3 _AP((union wait *, int, struct rusage *)); #endif #endif /* !__LYNXOS */ --- 94,101 ---- /* Function prototypes */ #ifndef __LYNXOS extern pid_t wait _AP((int *)); extern pid_t waitpid _AP((pid_t, int *, int)); ! #ifndef _POSIX_SOURCE ! extern int wait3 _AP((int *, int, struct rusage *)); #endif #endif /* !__LYNXOS */ *** ioctl.h Fri Apr 26 16:50:51 1996 --- ioctl.h Sat May 18 17:55:16 1996 *************** *** 572,576 **** #ifndef __LYNXOS ! extern int ioctl _AP((int, int, char *)); #endif --- 572,576 ---- #ifndef __LYNXOS ! extern int ioctl _AP((int, int, ...)); #endif *** stdarg.h Fri Apr 26 16:51:02 1996 --- stdarg.h Sat May 18 19:34:13 1996 *************** *** 88,92 **** (((sizeof(TYPE) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) ! #define va_start(AP, LASTARG) (AP = ((char *) __builtin_next_arg ())) void va_end(va_list); /* Defined in libgcc.a */ --- 88,92 ---- (((sizeof(TYPE) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) ! #define va_start(AP, LASTARG) (AP = ((char *) __builtin_next_arg (LASTARG))) void va_end(va_list); /* Defined in libgcc.a */ *************** *** 162,166 **** (((sizeof(TYPE) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) ! #define va_start(AP, LASTARG) (AP = ((char *) __builtin_next_arg ())) void va_end(va_list); /* Defined in libgcc.a */ --- 162,166 ---- (((sizeof(TYPE) + sizeof(int) - 1) / sizeof(int)) * sizeof(int)) ! #define va_start(AP, LASTARG) (AP = ((char *) __builtin_next_arg (LASTARG))) void va_end(va_list); /* Defined in libgcc.a */
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.