Yes, and also vim and other vi clones.
But what is the point of having a secure and integrated OS if you have to pull software from ports (which are not so thoroughly audited and tested as the main OS)?
One point of using BSD is (so the BSD people say) to have an operating system where everything comes from the same team - kernel and userland, unlike Linux where kernel and userland comes from dozens if not hundreds of different origins. But if you start to use arbitrary ports in BSD your OS is not much better than Linux in that regard
Historically, this is why basic vi (of whatever flavor) was so popular. I could hop on any Unix and it was there OOB. I dealt with some mixed set of Solaris, BSD, HP-UX, Irix, Tru64, AIX, and Linux for so long.
For a host I did primary development on, I’d install vim (visual mode and then syntax highlighting was so nice).
But we managed config centrally with idempotent scripts that handled the differences (like no getent on HP-UX). We did have to install ksh88 or a clone everywhere to get a stable consistent shell. GNU was flaky on so many platforms then.
Vi was always there for those WTF scenarios, less as a primary programming editor. And it is so nice on slow connections, where repainting the whole screen for every keystroke sucked.
It really annoyed me when Linuxes dropped the basic vi everywhere in favor of nano. I’d be fine with nano as a default for accessibility, but at least have some vi in my path.
Our standard images include it, but I always forget when I’m testing/debugging locally with Vagrant or a Docker image.
Vi is always a little weird. I don’t think any 2 people use it the same. Everyone has their own go-to set of commands. Pairing with grey beards influenced me so much.
I actually started with emacs in college, but real life with 1,000s of servers forced the change. I don’t have the muscle memory for it anymore and have no desire to go back.
Nowadays my local neovim config is almost VSCode. But I still like VSCode-ish in vi more than vi-ish in VSCode. I tried, but inevitably do something that VSCode’s vim plug-in doesn’t support.
I do use go more and more for complex stuff, but often am forced back to shell due to old kernels still out there which hurts my soul.
> It really annoyed me when Linuxes dropped the basic vi everywhere in favor of nano. I’d be fine with nano as a default for accessibility, but at least have some vi in my path.
Don’t nearly all distros still have something (usually nvi or vim) in /usr/bin/vi out of the box?
The behavior of the traditional vi is much different than vim and other clones. Nvi was a actually a re-implementation of the traditional vi for 4BSD (to be clean of AT&T code) and thus was originally intended to be bug-for-bug compatible, but breaking away where the original vi behavior was nonsensical or terrible.
For vim, `set compatible` or `set cp` is close, but still not traditional vi by any means.
Despite the very similar names, all of these editors have a variety of different features, and are structured very differently.
Nvi has a concept of a front-end and a back-end (which uses the BDB database). OpenVi uses the OpenBSD version of Berkeley DB which derives from 1.85. Nvi (1.8x) provides a minimal version of code also derived from that release intended from use with Nvi, and (IIRC) also provides support for using Db3/4/5. Similar situation for Nvi2.
Nvi 1.8 has been structured where a third library layer has been added, which doesn't exist in OpenBSD's vi or OpenVi. There is scripting support (Tcl, Perl, etc.) and GUI code in the other various forks ... all of these support various different options as well.
I should probably make a matrix of these, but you can get an idea by looking at the settable options implemented in each of the variants (as they historically include a comment to document from where the option originated):
One point of using BSD is (so the BSD people say) to have an operating system where everything comes from the same team - kernel and userland, unlike Linux where kernel and userland comes from dozens if not hundreds of different origins. But if you start to use arbitrary ports in BSD your OS is not much better than Linux in that regard