9 ms·

OpenVi: Portable OpenBSD vi for Unix systems

109 points by rdpintqogeogsaa 5y ago

hestefisk 5y ago
nvi is very fast.
- rnd0 5y ago
  Agreed; it's been my vi of choice for many, many years.
- wryun 5y ago
  I've found vile a good option as I'm addicted to syntax highlighting: similar speed to nvi, much faster than vis and vim. https://invisible-island.net/vile/ https://invisible-island.net/vile/
  - wryun 5y ago
    https://news.ycombinator.com/item?id=30396886 https://news.ycombinator.com/item?id=30396886
  - trn 5y ago
    I will confirm that Vile is an excellent editor. I don't know if I'd consider it a vi-clone, because the vi-ness is kind of skin-deep, but it's performant and works well. (In school, early 90's, there was a large vile following on VMS, which is where I mostly used it. I don't recall why it was preferred to Vim on VMS, however. Perhaps we didn't have Vim easily available or installed. But I digress.)
ruhrharry 5y ago
Last time I checked OpenBSD's vi didn't support utf8 - this is a show stopper in 2022.
- petepete 5y ago
  Vis looks like a very minimal but thoroughly modern alternative. https://github.com/martanne/vis https://github.com/martanne/vis
- trasz 5y ago
  I wonder if they could merge back utf8 patches from FreeBSD.
  - trn 5y ago
    This is something that I plan to tackle eventually, and in such as way the work can be contributed back to OpenBSD.
- john-aj 5y ago
  Indeed. Nvi, which was recommended elsewhere in the thread, supports UTF-8 and is my preferred vi clone. (Actually, OpenBSD vi is an old version of nvi without UTF-8 support.)
  - trn 5y ago
    I plan to eventually support multibyte in a way I can contribute upstream to OpenBSD. The 1.8 branch of the Nvi editor, as well as the Nvi2 fork have mulitbyte support. I could be mistaken but I believe both of these multibyte implementations descend from the late itojun's (http://www.itojun.org/itojun.html http://www.itojun.org/itojun.html) Nvi-m17n project (archived at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files). A paper was presented at USENIX99 (http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag...) describing the work, which was actually developed as part of the KAME project.
- anthk 5y ago
  You have nvi2 in ports.
  - ruhrharry 5y ago
    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
    - salmo 5y ago
      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.
- geokon 5y ago
  I look forward to config files in right to left Hebrew Or maybe Arabic so the characters flow into each other
  - bonzini 5y ago
    No need to wait, I'm sure many people have written their name in their native RTL script for git's "user.name" configuration key.
    - trn 5y ago
      For that level of UTF-8 editing, a non-mulitbyte version of the editor suffices. In fact, you can insert and modify multibyte signatures and names using the map facility, however the glyphs are not rendered on screen but are shown at the byte-level. Improvements are in order, and should be made, but the mere inability to visually render multibyte characters is not always a showstopper.
    - geokon 5y ago
      Do they right-align their command lines and files? Or once the Arabic exceeds 50% the alignment of the buffer flips? :)
  - selfhoster11 5y ago
    Or it could be just as simple as me jotting down some notes in my native language, which includes such exotic characters as ę and ą. You know, so I don't have to go back to using a code page like back in good old DOS days, that I'm actually too young to have lived through.
- doingtheiroming 5y ago
  Is it not a feature given how many security issues come out of parsing? There is virtue in the thing you’ll edit files with as root being as simple as you can make it.
- throwawayboise 5y ago
  It isn't for everyone. I have never come across a real need for more than standard ASCII in any of my work. It absolutely isn't needed for managing unix config files, which is the primary use case for "lightweight" editors like this.
  - selfhoster11 5y ago
    Congratulations on English being the one and only language you use to make quick notes, then. I personally mix in words from my native language wherever I need an extra bit of semantic precision, and I'd rather not have to switch between editors to do so.
    - kQq9oHeAz6wLLS 5y ago
      Not to sound dismissive, but that is a rather niche use case
      - selfhoster11 5y ago
        For multilinguals (which is over half of the world's population), throwing in terms from another language or entirely switching to a different language mid-sentence during a conversation is entirely normal. I can't imagine it being that rare in personal notes.
        kQq9oHeAz6wLLS 5y ago
        Sure, but how many of that number are keeping personal notes in vi?
        selfhoster11 5y ago
        Presumably, any number that prefer a terminal based workflow, or have the Vi key scheme burned into muscle memory. Or those that prefer an ultra-minimalist text editor for writing. Just a decade ago, it was almost a meme that the Emacs and Vi factions fought over which editor is better. I imagine that those that truly bought into the Vi ecosystem/fandom use it in preference to other available options.
thristian 5y ago
Why would somebody want to use this over nvi, elvis, or the original BSD vi? (I assume that people who are interested in features already know where to find (Neo)Vim.)
- rnd0 5y ago
  >Why would somebody want to use this over nvi This basically is nvi, unless I'm very wrong.
  - mrweasel 5y ago
    It's nvi plus some OpenBSD patches. Nvi it self has a series of different patches. The question remains valid. Why would you specifically want the nvi from OpenBSD, when you already have nvi? The assumption has to be that OpenBSD added something to their version of nvi, which would "justify" porting it back to non-OpenBSD systems. What those feature are I don't know. It might just be a fun exercise adding the portability back.
    - trn 5y ago
      I have some comments here that address this, but, there are in fact many significant differences. The OpenBSD version forked at Nvi 1.79 around 1996-1997 and has been developed in the OpenBSD base system for 25 years now, and has diverged greatly from Nvi. Nvi2 has also diverged significantly from both "upstream" Nvi and OpenBSD vi. The OpenBSD release has significantly trimmed features and maintains a different structure than the others as the philosophy completely different. There is no Perl / Tcl / pluggable scripting engine support or alternate graphical user interfaces or similar. There are significant differences in the lower level code for signal handling, options, etc. While the core functionality of these editors are all largely the same, and they all share common heritage from Bostic's Nvi, there are trivial and non-trivial differences between all of these editors that are almost too numerous to summarize. Reviewing the ChangeLog (https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch...) since Nvi 1.79 to present should give you an idea of what's going on with this particular version.
ayushnix 5y ago
I've been using busybox vi as my root editor but it doesn't have secure mode which disables shell access within vi. It looks like OpenVi and nvi2 have them. Are they preferable to busybox vi if I want better security as a root editor?
- pletnes 5y ago
  If you’re that paranoid, isn’t it better to run the editor on some other machine? E.g vim with scp support? Then there’s no editor to infect/replace/screw with on the Important Server.
- mprovost 5y ago
  Secure mode doesn't really make anything more secure if you're the one using it. It just lets you add it to the list of allowed commands in the sudoers file without giving someone a root shell. We used to do that all the time at one job that didn't let you log in as root and wanted you to do everything through sudo. You'd just sudo vi /some/random/file and then :! and have a root shell.
- trn 5y ago
  OpenVi uses only secure functions (snprintf, strlcpy, etc.) as a matter of policy. This may lead to a more secure editor for untrusted files, but it depends on how careful the other editors are. (I haven't examined them at that level.)
tambourine_man 5y ago
Isn’t vi already in POSIX? What’s the advantage over what OpenBSD should include already?
- mrweasel 5y ago
  It's the other way around. It's the OpenBSD vi (which is a fork of nvi) ported back to other Unix(-like) systems. Still it's unclear why.
  - trn 5y ago
    I have updated the documentation/README to provide background and rationale, and elaborated a bit on other comments. OpenBSD's vi (and OpenVi) differ distinctly from both Nvi (https://repo.or.cz/nvi.git https://repo.or.cz/nvi.git) and Nvi2 (https://github.com/lichray/nvi2 https://github.com/lichray/nvi2) in terms of features and support, having diverged 25 years previously, where the OpenBSD/OpenVi branch has embraced minimalism and simplicity. For a quick and non-scientific comparison, C source lines of code (as counted by tokei) for the various distributions of the Nvi-derived editors: Nvi - 62,315 SLOC Nvi2 - 32,408 SLOC OpenVi - 40,065 SLOC And looking ONLY at the core editor functionality and bundled regular expression engines: Nvi - 35,874 SLOC Nvi2 - 32,019 SLOC OpenVi - 31,678 SLOC
vermaden 5y ago
Its really pity that you can not disable wrapping in nvi(1) ...
- bch 5y ago
  :set [no]leftright
  - vermaden 5y ago
    Thank You! I have searched for this some time ago but all 'hints' guided me towards vim(1) :set nowrap option. I checked now the vi(1) [nvi] man page on FreeBSD and it indeed has leftright option. % man vi | grep -A 1 leftright leftright [off] vi only. Do left-right scrolling. But I never interpreted that as 'nowrap' equivalent. Thanks again and have a great life.
    - bch 5y ago
      Cheers. Edit in good health.
mst 5y ago
If you want to go ultimately minimalist http://ex-vi.sourceforge.net/ http://ex-vi.sourceforge.net/ builds and runs on most modern systems just fine. Having learned vi across eight-ish different unices at once my muscle memory is very minimalist so I tend to use ex-vi preferentially, simply because everything else adds features I don't use that I can accidentally activate with a typo and break myself out of flow figuring out wtf just happened. I can absolutely imagine that for somebody who tends to use OpenBSD on their own machines, being able to have the exact same editor elsewhere could be really quite handy for much the same reasons.
- throwawayboise 5y ago
  OpenBSD also includes mg, which is a "minimalist emacs" for people who don't want to install the full emacs port but who have emacs muscle memory.
  - trn 5y ago
    pEmacs is "even better" for minimalists. https://github.com/hughbarney/pEmacs https://github.com/hughbarney/pEmacs Stripped -Os build using link-time GC on Linux x86_64 glibc: 30 KB pe* Compare to portable mg: 132 KB mg* OpenVi is ... 278 KB bin/vi* An even smaller vi implementation is Xvi. 56 KB src/xvi* This would be an 'ersatz' vi since it is not built on top of a real ex-mode. Even tinier ersatz-vi clones exist (`levee`, `s`, `VIrus`) but these are not complete implementations.
- trn 5y ago
  Using Carsten Kunze's actively maintained continuation of Gunnar Ritter's (outstanding) traditional ex/vi project is highly recommended. See https://github.com/n-t-roff/heirloom-ex-vi/ https://github.com/n-t-roff/heirloom-ex-vi/. The parent project on SourceForge hasn't had any activity for 15 years, nor a release in 17+ years, and contains various known bugs, all of which are fixed in Carsten Kunze's project.
  - mst 5y ago
    That sounds like a better idea for everybody who isn't me. Naturally I've accumulated a few local patches over the years so I'll have to figure out which of them are obsoleted by the improvements in that version and which of them I want to port first ;) (thanks very much for sharing that this exists though, I shall be digging in when I have available tuits)
DarylZero 5y ago
https://github.com/neovim/neovim/wiki/Installing-Neovim https://github.com/neovim/neovim/wiki/Installing-Neovim
- wolverine876 5y ago
  The NeoVim people are now spamming HN with ads?
  - DarylZero 5y ago
    20% discount with coupon code #NEWERVIMIER2022
trn 5y ago
It isn't really an "old" version of Nvi by any means - the development went in a different direction. OpenBSD's vi has been developed mostly independently since being imported back in 1997. The documentation has been updated to explain the rationale - see https://github.com/johnsonjh/OpenVi#why https://github.com/johnsonjh/OpenVi#why In the 25 years since the "fork", OpenBSD vi has diverged significantly from Nvi1 (as Nvi2 has diverged from Nvi1 as well). It has grown much smaller and more compact - one might argue more focused. Much of the code has been simplified and many features removed, rather than added. Still, it has adopted features and taken some fixes back from Nvi1/Nvi2 versions and other variants, such as adopting support for expandtab from NetBSD's variant. You can get a good idea of the history of this particular fork by reviewing the ChangeLog at https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch... where the OpenBSD changes begin in 1997.
trn 5y ago
Hi, I'm the "perpetrator" responsible for OpenVi. Apologies to everyone! /s I've added details to the README to hopefully explain why it exists: https://github.com/johnsonjh/OpenVi#why https://github.com/johnsonjh/OpenVi#why The OpenVi ChangeLog at https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch... includes all the history going back to 1993's Nvi 0.93. Nvi 1.79 was released in 1996, which is the version OpenBSD's vi was derived from. The ChangeLog entries are only a summary of the full commit messages - the complete details are in OpenBSD's CVS tree, and viewable a bit easier via GitHub (https://github.com/openbsd/src/commits/master/usr.bin/vi https://github.com/openbsd/src/commits/master/usr.bin/vi) Changes to the (OpenVi bundled) OpenBSD regular expression engine are not included in the legacy ChangeLog, but you can see that development in the CVS tree or via GitHub as well (https://github.com/openbsd/src/commits/master/lib/libc/regex https://github.com/openbsd/src/commits/master/lib/libc/regex). OpenVi also utilizes the OpenBSD version of Berkely DB (https://github.com/openbsd/src/commits/master/lib/libc/db https://github.com/openbsd/src/commits/master/lib/libc/db).
deleted 5y ago
[deleted]
trn 5y ago
Cleanly doing UTF-8 support (the "right" way) is planned but is certainly non-trivial ... for example, see: https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf and http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag... Nvi2 (and Nvi1) are excellent editors, but I wouldn't want to copy the Nvi2 implementation directly. This has been talked about elsewhere* * https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#post4 https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#po...

hestefisk 5y ago

nvi is very fast.

rnd0 5y ago
Agreed; it's been my vi of choice for many, many years.
wryun 5y ago
I've found vile a good option as I'm addicted to syntax highlighting: similar speed to nvi, much faster than vis and vim. https://invisible-island.net/vile/ https://invisible-island.net/vile/
- wryun 5y ago
  https://news.ycombinator.com/item?id=30396886 https://news.ycombinator.com/item?id=30396886
- trn 5y ago
  I will confirm that Vile is an excellent editor. I don't know if I'd consider it a vi-clone, because the vi-ness is kind of skin-deep, but it's performant and works well. (In school, early 90's, there was a large vile following on VMS, which is where I mostly used it. I don't recall why it was preferred to Vim on VMS, however. Perhaps we didn't have Vim easily available or installed. But I digress.)

ruhrharry 5y ago

Last time I checked OpenBSD's vi didn't support utf8 - this is a show stopper in 2022.

petepete 5y ago
Vis looks like a very minimal but thoroughly modern alternative. https://github.com/martanne/vis https://github.com/martanne/vis
trasz 5y ago
I wonder if they could merge back utf8 patches from FreeBSD.
- trn 5y ago
  This is something that I plan to tackle eventually, and in such as way the work can be contributed back to OpenBSD.
john-aj 5y ago
Indeed. Nvi, which was recommended elsewhere in the thread, supports UTF-8 and is my preferred vi clone. (Actually, OpenBSD vi is an old version of nvi without UTF-8 support.)
- trn 5y ago
  I plan to eventually support multibyte in a way I can contribute upstream to OpenBSD. The 1.8 branch of the Nvi editor, as well as the Nvi2 fork have mulitbyte support. I could be mistaken but I believe both of these multibyte implementations descend from the late itojun's (http://www.itojun.org/itojun.html http://www.itojun.org/itojun.html) Nvi-m17n project (archived at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files). A paper was presented at USENIX99 (http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag...) describing the work, which was actually developed as part of the KAME project.
anthk 5y ago
You have nvi2 in ports.
- ruhrharry 5y ago
  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
  - salmo 5y ago
    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.
geokon 5y ago
I look forward to config files in right to left Hebrew Or maybe Arabic so the characters flow into each other
- bonzini 5y ago
  No need to wait, I'm sure many people have written their name in their native RTL script for git's "user.name" configuration key.
  - trn 5y ago
    For that level of UTF-8 editing, a non-mulitbyte version of the editor suffices. In fact, you can insert and modify multibyte signatures and names using the map facility, however the glyphs are not rendered on screen but are shown at the byte-level. Improvements are in order, and should be made, but the mere inability to visually render multibyte characters is not always a showstopper.
  - geokon 5y ago
    Do they right-align their command lines and files? Or once the Arabic exceeds 50% the alignment of the buffer flips? :)
- selfhoster11 5y ago
  Or it could be just as simple as me jotting down some notes in my native language, which includes such exotic characters as ę and ą. You know, so I don't have to go back to using a code page like back in good old DOS days, that I'm actually too young to have lived through.
doingtheiroming 5y ago
Is it not a feature given how many security issues come out of parsing? There is virtue in the thing you’ll edit files with as root being as simple as you can make it.
throwawayboise 5y ago
It isn't for everyone. I have never come across a real need for more than standard ASCII in any of my work. It absolutely isn't needed for managing unix config files, which is the primary use case for "lightweight" editors like this.
- selfhoster11 5y ago
  Congratulations on English being the one and only language you use to make quick notes, then. I personally mix in words from my native language wherever I need an extra bit of semantic precision, and I'd rather not have to switch between editors to do so.
  - kQq9oHeAz6wLLS 5y ago
    Not to sound dismissive, but that is a rather niche use case
    - selfhoster11 5y ago
      For multilinguals (which is over half of the world's population), throwing in terms from another language or entirely switching to a different language mid-sentence during a conversation is entirely normal. I can't imagine it being that rare in personal notes.
      - kQq9oHeAz6wLLS 5y ago
        Sure, but how many of that number are keeping personal notes in vi?
        selfhoster11 5y ago
        Presumably, any number that prefer a terminal based workflow, or have the Vi key scheme burned into muscle memory. Or those that prefer an ultra-minimalist text editor for writing. Just a decade ago, it was almost a meme that the Emacs and Vi factions fought over which editor is better. I imagine that those that truly bought into the Vi ecosystem/fandom use it in preference to other available options.

thristian 5y ago

Why would somebody want to use this over nvi, elvis, or the original BSD vi? (I assume that people who are interested in features already know where to find (Neo)Vim.)

rnd0 5y ago
>Why would somebody want to use this over nvi This basically is nvi, unless I'm very wrong.
- mrweasel 5y ago
  It's nvi plus some OpenBSD patches. Nvi it self has a series of different patches. The question remains valid. Why would you specifically want the nvi from OpenBSD, when you already have nvi? The assumption has to be that OpenBSD added something to their version of nvi, which would "justify" porting it back to non-OpenBSD systems. What those feature are I don't know. It might just be a fun exercise adding the portability back.
  - trn 5y ago
    I have some comments here that address this, but, there are in fact many significant differences. The OpenBSD version forked at Nvi 1.79 around 1996-1997 and has been developed in the OpenBSD base system for 25 years now, and has diverged greatly from Nvi. Nvi2 has also diverged significantly from both "upstream" Nvi and OpenBSD vi. The OpenBSD release has significantly trimmed features and maintains a different structure than the others as the philosophy completely different. There is no Perl / Tcl / pluggable scripting engine support or alternate graphical user interfaces or similar. There are significant differences in the lower level code for signal handling, options, etc. While the core functionality of these editors are all largely the same, and they all share common heritage from Bostic's Nvi, there are trivial and non-trivial differences between all of these editors that are almost too numerous to summarize. Reviewing the ChangeLog (https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch...) since Nvi 1.79 to present should give you an idea of what's going on with this particular version.

ayushnix 5y ago

I've been using busybox vi as my root editor but it doesn't have secure mode which disables shell access within vi. It looks like OpenVi and nvi2 have them. Are they preferable to busybox vi if I want better security as a root editor?

pletnes 5y ago
If you’re that paranoid, isn’t it better to run the editor on some other machine? E.g vim with scp support? Then there’s no editor to infect/replace/screw with on the Important Server.
mprovost 5y ago
Secure mode doesn't really make anything more secure if you're the one using it. It just lets you add it to the list of allowed commands in the sudoers file without giving someone a root shell. We used to do that all the time at one job that didn't let you log in as root and wanted you to do everything through sudo. You'd just sudo vi /some/random/file and then :! and have a root shell.
trn 5y ago
OpenVi uses only secure functions (snprintf, strlcpy, etc.) as a matter of policy. This may lead to a more secure editor for untrusted files, but it depends on how careful the other editors are. (I haven't examined them at that level.)

tambourine_man 5y ago

Isn’t vi already in POSIX? What’s the advantage over what OpenBSD should include already?

mrweasel 5y ago
It's the other way around. It's the OpenBSD vi (which is a fork of nvi) ported back to other Unix(-like) systems. Still it's unclear why.
- trn 5y ago
  I have updated the documentation/README to provide background and rationale, and elaborated a bit on other comments. OpenBSD's vi (and OpenVi) differ distinctly from both Nvi (https://repo.or.cz/nvi.git https://repo.or.cz/nvi.git) and Nvi2 (https://github.com/lichray/nvi2 https://github.com/lichray/nvi2) in terms of features and support, having diverged 25 years previously, where the OpenBSD/OpenVi branch has embraced minimalism and simplicity. For a quick and non-scientific comparison, C source lines of code (as counted by tokei) for the various distributions of the Nvi-derived editors: Nvi - 62,315 SLOC Nvi2 - 32,408 SLOC OpenVi - 40,065 SLOC And looking ONLY at the core editor functionality and bundled regular expression engines: Nvi - 35,874 SLOC Nvi2 - 32,019 SLOC OpenVi - 31,678 SLOC

vermaden 5y ago

Its really pity that you can not disable wrapping in nvi(1) ...

bch 5y ago
:set [no]leftright
- vermaden 5y ago
  Thank You! I have searched for this some time ago but all 'hints' guided me towards vim(1) :set nowrap option. I checked now the vi(1) [nvi] man page on FreeBSD and it indeed has leftright option. % man vi | grep -A 1 leftright leftright [off] vi only. Do left-right scrolling. But I never interpreted that as 'nowrap' equivalent. Thanks again and have a great life.
  - bch 5y ago
    Cheers. Edit in good health.

mst 5y ago

If you want to go ultimately minimalist http://ex-vi.sourceforge.net/ http://ex-vi.sourceforge.net/ builds and runs on most modern systems just fine. Having learned vi across eight-ish different unices at once my muscle memory is very minimalist so I tend to use ex-vi preferentially, simply because everything else adds features I don't use that I can accidentally activate with a typo and break myself out of flow figuring out wtf just happened. I can absolutely imagine that for somebody who tends to use OpenBSD on their own machines, being able to have the exact same editor elsewhere could be really quite handy for much the same reasons.

throwawayboise 5y ago
OpenBSD also includes mg, which is a "minimalist emacs" for people who don't want to install the full emacs port but who have emacs muscle memory.
- trn 5y ago
  pEmacs is "even better" for minimalists. https://github.com/hughbarney/pEmacs https://github.com/hughbarney/pEmacs Stripped -Os build using link-time GC on Linux x86_64 glibc: 30 KB pe* Compare to portable mg: 132 KB mg* OpenVi is ... 278 KB bin/vi* An even smaller vi implementation is Xvi. 56 KB src/xvi* This would be an 'ersatz' vi since it is not built on top of a real ex-mode. Even tinier ersatz-vi clones exist (`levee`, `s`, `VIrus`) but these are not complete implementations.
trn 5y ago
Using Carsten Kunze's actively maintained continuation of Gunnar Ritter's (outstanding) traditional ex/vi project is highly recommended. See https://github.com/n-t-roff/heirloom-ex-vi/ https://github.com/n-t-roff/heirloom-ex-vi/. The parent project on SourceForge hasn't had any activity for 15 years, nor a release in 17+ years, and contains various known bugs, all of which are fixed in Carsten Kunze's project.
- mst 5y ago
  That sounds like a better idea for everybody who isn't me. Naturally I've accumulated a few local patches over the years so I'll have to figure out which of them are obsoleted by the improvements in that version and which of them I want to port first ;) (thanks very much for sharing that this exists though, I shall be digging in when I have available tuits)

DarylZero 5y ago

https://github.com/neovim/neovim/wiki/Installing-Neovim https://github.com/neovim/neovim/wiki/Installing-Neovim

wolverine876 5y ago
The NeoVim people are now spamming HN with ads?
- DarylZero 5y ago
  20% discount with coupon code #NEWERVIMIER2022

trn 5y ago

It isn't really an "old" version of Nvi by any means - the development went in a different direction. OpenBSD's vi has been developed mostly independently since being imported back in 1997. The documentation has been updated to explain the rationale - see https://github.com/johnsonjh/OpenVi#why https://github.com/johnsonjh/OpenVi#why In the 25 years since the "fork", OpenBSD vi has diverged significantly from Nvi1 (as Nvi2 has diverged from Nvi1 as well). It has grown much smaller and more compact - one might argue more focused. Much of the code has been simplified and many features removed, rather than added. Still, it has adopted features and taken some fixes back from Nvi1/Nvi2 versions and other variants, such as adopting support for expandtab from NetBSD's variant. You can get a good idea of the history of this particular fork by reviewing the ChangeLog at https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch... where the OpenBSD changes begin in 1997.

trn 5y ago

Hi, I'm the "perpetrator" responsible for OpenVi. Apologies to everyone! /s I've added details to the README to hopefully explain why it exists: https://github.com/johnsonjh/OpenVi#why https://github.com/johnsonjh/OpenVi#why The OpenVi ChangeLog at https://raw.githubusercontent.com/johnsonjh/OpenVi/master/ChangeLog https://raw.githubusercontent.com/johnsonjh/OpenVi/master/Ch... includes all the history going back to 1993's Nvi 0.93. Nvi 1.79 was released in 1996, which is the version OpenBSD's vi was derived from. The ChangeLog entries are only a summary of the full commit messages - the complete details are in OpenBSD's CVS tree, and viewable a bit easier via GitHub (https://github.com/openbsd/src/commits/master/usr.bin/vi https://github.com/openbsd/src/commits/master/usr.bin/vi) Changes to the (OpenVi bundled) OpenBSD regular expression engine are not included in the legacy ChangeLog, but you can see that development in the CVS tree or via GitHub as well (https://github.com/openbsd/src/commits/master/lib/libc/regex https://github.com/openbsd/src/commits/master/lib/libc/regex). OpenVi also utilizes the OpenBSD version of Berkely DB (https://github.com/openbsd/src/commits/master/lib/libc/db https://github.com/openbsd/src/commits/master/lib/libc/db).

deleted 5y ago

[deleted]

trn 5y ago

Cleanly doing UTF-8 support (the "right" way) is planned but is certainly non-trivial ... for example, see: https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf https://www.openbsd.org/papers/eurobsdcon2016-utf8.pdf and http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag... Nvi2 (and Nvi1) are excellent editors, but I wouldn't want to copy the Nvi2 implementation directly. This has been talked about elsewhere* * https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#post4 https://misc.openbsd.narkive.com/9NHoQv8L/nvi-and-unicode#po...