Marc Espie writes: > On Thu, Mar 17, 2016 at 12:00:47AM -0600, Anthony J. Bentley wrote: > > I'm concerned about this port, though. It's an unmaintained ISO-2022 > > patchset on top of less-332, which was released in *1997*. The patches > > no longer exist except on our mirrors. Have there been any > > vulnerabilities in less in the past 19 years? Do the patches introduce > > any? > > > > It seems like it might be worthwhile for jless users to alias it to > > "iconv -f iso-2022-jp -t utf-8 | less", and see if it acts as a > > reasonable approximation. > > > > I'm very concerned about keeping such an old, unmaintained fork in > > our tree, when the original software has since grown its own support > > for Japanese. I have similar concerns about kterm (1996 xterm), > > jvim (1996 vim), ja-groff (1995 groff), hanterm-xf (2003 xterm)... > > I don't know. Japanese is slightly peculiar, and they sometimes have needs > that haven't gotten to the 21st century... > > keeping a toolchain that works with JIS/SJIS encoding probably makes some > sense. > > Analogy with western countries: we just switched to utf8 by default less > than a release ago. before that, a lot of people, me included were still > mostly working with iso-8859-*
I do understand. But I'm very leery of promoting such old, old software. I'm not convinced that we're doing anybody a favor by keeping these ports around. If 20-year-old packages exist under japanese/, that's an implicit endorsement that "to set up a Japanese environment, you need to use this special terminal with a special encoding that nothing else on the system uses." I saw this happen even last year on misc@. That is a bad thing to promote, because there is no future for ISO-2022 or Shift-JIS on OpenBSD. By analogy, we used to have nvi-m17n in ports. But it turns out the nvi port supported the same encodings and more; and has a somewhat maintained upstream. It was worth removing nvi-m17n and encouraging people to use nvi instead. I understand that people sometimes, even frequently, need to work with non-UTF encodings. But you can get that effect on OpenBSD with a UTF-8 locale and using iconv on incoming and outgoing data. I've been doing so for Japanese and European content for over six years. Base xterm works natively with Japanese text out of the box; you don't even need to install any fonts. And if you have to, you can even run Shift-JIS/ISO-2022 software directly in xterm using luit(1). Promoting use of a parallel xterm with a parallel less and a parallel vim, all unmaintained for decade after decade after decade, is *harmful*. -- Anthony J. Bentley
