Building tcsh on 4.3BSD-Quasijarus

So after build installing 4.3BSD on simh I was left with a somewhat bare environment.
My first need was a better shell than stock csh with history & tab completion. I proceeded to download the latest version of tcsh to attempt a build.
Things fell into place quickly as I realised this was not going to be as straight forward.
At some point in the development path of tcsh, support for the GNU tool chain was added which would allow one to use autotools to build the software.
Bootstrapping the baseline is always a lengthy pain which prepackaged binaries ease. I was reminded of the period I avoided using OpenBSD-CURRENT because I was unaware packages were available so I would resort to painfully long builds as I started to tried to compile firefox on a freshly installed system.
I decided to see how far I can get in building software without the introduction GNU components, not using up to date versions is acceptable just so I can achieve the task. This also falls in line with the philosophy of the 4.3BSD-Quasijarus project.

I struggled to get tcsh 6.18.01 to build so thought I’d try the earliest version I could find on the official mirror to see if that would work any better.
Version 6.00 is the earliest one available on the US FTP site, the README file references 4.2 & 4.3BSD among a whole bunch of other legacy OS’s & no sign of GNU autoconf.
With a bit of experimentation I had tcsh compiled, essentially just needed to undefine functionality that was not present in my stock install (NLS) or available in the version I was running (better POSIX compliance).
There is lots of code which is spaced out so as to disable its functionality requiring the deletion of the spaces to re-enable depending on the intended target.
This approach assumes knowledge of the OS & its capabilities along with the functionality enabled in the version installed as apposed to the autotools approach where the developer is responsible for putting together something which in theory will reduced the requirement from the end user installing the software to running configure & make.
In my opinion it’s an idea which is poorly executed while not actually solving the problem, instead pushing the responsiblity from one end to the other with added complexity.
I discovered through an interview with Larry Wall that he was responsible for the patch utility we commonly use, I was curious to see how it would function on 4.3BSD & to my surprise there was no patch utility in base. There is the diff utility for generating differential patches but no support for unified context just copied context. You can generate scripts for ed which can be used to apply the changes for subsequent users.

To build tcsh on 4.3BSD Qausijarus
Fetch the tcsh-6.00.00.tar.gz from FTP
Uncompress with
gzcompat tcsh-6.00.00.tar.gz | uncompress | tar xf -

Copy tcsh-6.00/config/config.bsdreno to tcsh-6.00/config.h

Apply the following changes in this diff to your source & build by running make

By default, the install process puts files into /usr/local so you’ll need to create /usr/local/bin & /usr/local/man

> echo $version
tcsh 6.00.00 (Cornell) 07/04/91 options 8b,dl,al,dir

Last week I came across a project to develop 4.5BSD, a continuation from where 4.4BSD stopped. Comparing the current state of the modern BSD derivatives, we’ve come a long long way, with effort going in to reduce the need to bring the system to a useable state post install & shipping with sane defaults we are in a much better place. 20 years worth of changes to back port is a serious effort.

Screenshot of a tweet, stating "4.5BSD - This project aims to stay as close to the original Berkeley UNIX sources as possible followed by Debian APT"