[HN Gopher] OpenVi: Portable OpenBSD vi for Unix systems
___________________________________________________________________
OpenVi: Portable OpenBSD vi for Unix systems
Author : rdpintqogeogsaa
Score : 97 points
Date : 2022-02-19 06:56 UTC (16 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hestefisk wrote:
| nvi is very fast.
| rnd0 wrote:
| Agreed; it's been my vi of choice for many, many years.
| wryun wrote:
| 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/
| wryun wrote:
| https://news.ycombinator.com/item?id=30396886
| trn wrote:
| 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
|
| 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/Ch...
| where the OpenBSD changes begin in 1997.
| tambourine_man wrote:
| Isn't vi already in POSIX? What's the advantage over what OpenBSD
| should include already?
| mrweasel wrote:
| 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 wrote:
| 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) and 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 wrote:
| Its really pity that you can not disable wrapping in nvi(1) ...
| bch wrote:
| :set [no]leftright
| vermaden wrote:
| 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.
| ruhrharry wrote:
| Last time I checked OpenBSD's vi didn't support utf8 - this is a
| show stopper in 2022.
| john-aj wrote:
| 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 wrote:
| 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) Nvi-m17n project
| (archived at
| https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files).
| A paper was presented at USENIX99 (http://www.usenix.org/even
| ts/usenix99/full_papers/hagino/hag...) describing the work,
| which was actually developed as part of the KAME project.
| anthk wrote:
| You have nvi2 in ports.
| ruhrharry wrote:
| 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 wrote:
| 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.
| umanwizard wrote:
| > 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?
| trn wrote:
| 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.
|
| A multibyte variant of the traditional vi is maintained
| at https://github.com/n-t-roff/heirloom-ex-vi/.
|
| Nvi (now on version 1.8x) is also maintained -
| https://repo.or.cz/nvi.git
|
| Nvi2 is yet another fork of Nvi,
| https://github.com/lichray/nvi2
|
| 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):
|
| OpenVi: https://github.com/johnsonjh/OpenVi/blob/22c2a702
| 2e31d91e09e...
|
| OpenBSD vi: https://github.com/openbsd/src/blob/master/us
| r.bin/vi/common...
|
| Nvi2: https://github.com/lichray/nvi2/blob/5fcdc13656500a
| 8c5b4c073...
|
| Nvi1: https://repo.or.cz/nvi.git/blob/HEAD:/common/option
| s.c#l52
| doingtheiroming wrote:
| 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 wrote:
| 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 wrote:
| 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.
| trasz wrote:
| I wonder if they could merge back utf8 patches from FreeBSD.
| trn wrote:
| This is something that I plan to tackle eventually, and in
| such as way the work can be contributed back to OpenBSD.
| geokon wrote:
| I look forward to config files in right to left Hebrew
|
| Or maybe Arabic so the characters flow into each other
| bonzini wrote:
| 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 wrote:
| 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.
| selfhoster11 wrote:
| Or it could be just as simple as me jotting down some notes
| in my native language, which includes such exotic characters
| as e and a. 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.
| petepete wrote:
| Vis looks like a very minimal but thoroughly modern
| alternative.
|
| https://github.com/martanne/vis
| trn wrote:
| 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
|
| The OpenVi ChangeLog at
| 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)
|
| 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).
|
| OpenVi also utilizes the OpenBSD version of Berkely DB
| (https://github.com/openbsd/src/commits/master/lib/libc/db).
| [deleted]
| mst wrote:
| If you want to go ultimately minimalist 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 wrote:
| 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.
| thristian wrote:
| 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 wrote:
| >Why would somebody want to use this over nvi
|
| This basically is nvi, unless I'm very wrong.
| mrweasel wrote:
| 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 wrote:
| 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/Ch...) since Nvi 1.79 to present
| should give you an idea of what's going on with this
| particular version.
| anthk wrote:
| That "nvi" is nvi2 at OpenBSD ports.
|
| On features, most people would be fine with a vi clone with
| utf8 support.
| DarylZero wrote:
| https://github.com/neovim/neovim/wiki/Installing-Neovim
| ayushnix wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-19 23:02 UTC)