🚀 go-pugleaf

>Okay, the next thing I tried was to port the System V vi to the Sun4 (SUNOS
>4.0.1).  It quickly began to look like a major hacking headache.  Simple
>compilation under the so-called "System V universe" won't fly:  there are
>things which are not #defined that are supposed to be #defined, things which
>are not declared that are supposed to be declared, etc., etc., arrrrrrrgh!!!!

The crux of the problem is that the System V implementation has changed
at various times, and "vi" depends on characteristics of the
implementation.  The SunOS System V environment is based on recent
versions of the SVID; it doesn't promise that everything will look
*exactly* as it does on your 3B.

For example, the S5R3 "vi" assumes that you have the *UNDOCUMENTED*
"-lgen" library.  One is tempted to ask why, if this library is so
bloody wonderful, it's not documented?  It's sure not in the SVID. 

It also assumes you have the "-lcrypt" library.  The main reason for
this library is to isolate the encryption code, so as to make it easier
to make "domestic" and "international" releases of S5.  It turns out
that, for various reasons, that doesn't help for SunOS, so that
particular bit of technology wasn't adopted.  It's not in the SVID
either....

It also includes "term.h" but not "curses.h".  Unfortunately, while the
S5R3 "term.h" doesn't require you to include "curses.h", the S5R3.1 one
*does* - and the S5 "curses" in SunOS 4.0 is based on the S5R3.1 one. 
The S5R3.1 "vi" handles this by independently defining a few items from
"curses.h" (and solemnly informing you in a comment that you have to
keep those definitions in sync with the ones in "curses"); however, the
S5R3.1 "vi" depends on S5R3.1's rather, umm, *idiosyncratic*
internationalization support - SunOS 4.0 doesn't have that, and SunOS
4.1's internationalization support matches that from the draft ANSI C
standard, rather than S5R3.1's.

On top of that, the S5R3 "vi" assumes that you can't have job control in
a "System V" system; this is, of course, not true - the SunOS S5
environment has it, as do, I think, recent versions of HP-UX, and the S5
environment of Ultrix - and, of course, S5R4....

There is also a bug in the Sun-4 version of the S5 C library - one of
the routines in it appears to be a Sun-2 version.  This may be fixed in
4.0.1; we haven't installed it yet.

Had "vi" been written solely to the SVID, had it more carefully
#ifdeffed the job control support, it should have built, modulo bugs
such as the one listed.

There's a reason why things such as the SVID, and POSIX, and the
forthcoming ANSI C standard, exist; they exist to give
implementation-independent promises about the environment.  Said
promises stand a better chance of being honored in multiple environments
than promises from one particular vendor's manual pages - or, worse, one
particular vendor's *source code*....