The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Marc Rochkind <mrochkind@gmail.com>
To: TUHS main list <tuhs@tuhs.org>
Subject: [TUHS] Re: On Bloat and the Idea of Small Specialized Tools
Date: Sun, 19 May 2024 11:39:32 +0300	[thread overview]
Message-ID: <CAOkr1zUeW9cMt=Dk+bXbRtCkh=m7bZtkKNaqO8zF43kxt6V+ww@mail.gmail.com> (raw)
In-Reply-To: <20240518203319.3oAKtOSk@steffen%sdaoden.eu>

[-- Attachment #1: Type: text/plain, Size: 5455 bytes --]

UNIX man pages were almost universally accurate, complete, and succinct.

That third admirable attribute gave me the opportunity to write *Advanced
UNIX Programming*.

So I wasn't complaining.

Marc

On Sat, May 18, 2024, 11:33 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Douglas McIlroy wrote in
>  <CAKH6PiXaYGEUmVFRX99eM6s3+nTJrbVvkuBRa-Awhhd69xzJrg@mail.gmail.com>:
>  |I just revisited this ironic echo of Mies van der Rohe's aphorism, "Less
> is
>  |more".
>  |       % less --help | wc
>  |      298
>  |Last time I looked, the line count was about 220. Bloat is
> self-catalyzing.
>
> I do not buy that.
> You are working on Windows and in the meantime have switched to
> one of those graphical browser monsters (i think) where each
> instance has more code active than the entire Unix history
> altogether.
>
> less(1) can now Unicode, and that is not as easy with ISO/POSIX as
> it was on Plan9 for example which simply goes UTF-8 and has some
> (smart) lookup tables (now in go, more or less, last i looked),
> but that is not the whole picture of it.
>
> It can those ANSI / ISO 6429 color sequences that everybody wants,
> as you have them everywhere, even GNU's yacc, bison.
>
> The OpenBSD people took a port done by an OpenSolaris (i think,
> that scene, anyhow) guy, and together they stripped it down
> massively.
>
> But i do not use it, because after almost exactly a decade i got
> upstreamed to Nudelman's less(1) the necessary patches to have
> active hyperlinks on the terminal, in a normal Unix (roff mdoc)
> manual.  (These work via OSC-8 escape sequences; it was a "15
> files changed, 601 insertions(+), 9 deletions(-)" patch, which
> included careful quoting of file paths etc. for man(1) openings
> (ie, such code gets lengthy), but he did it differently a bit, and
> left off some things i wanted, included others (good), but if you
> use --mouse with his one then you have a real browser feeling.
> I have problems with --mouse, unfortunately, because when used you
> can no longer copy+paste -- he would need to add clipboard control
> in addition i'd say.., adding even more code.)
>
> You know, it may be viable for some tools, but for others, .. not.
> You say it yourself in your "A Research UNIX Reader": "Electronic
> mail was there from the start.  Never satisfied with its exact
> behavior, everybody touched it at one time or another".
> In the meantime the IETF went grazy and produced masses of
> standards, and unfortunately each one adds a little bit that needs
> to be addressed differently, and all that needs documentation.
> Now mail is an extreme example.
>
> And almost a quarter of a century ago i wrote a small pager that
> even had a clock, and it required less CPU on a day with some
> scrolling than less/ncurses for a one time scroll through the
> document.  But that pager is history, and less is still there,
> running everywhere, and being used by me dozens to hundreds time
> a day.  Also with colours, with searching, and now also with
>
>   ^O^N  ^On         *  Search forward for (N-th) OSC8 hyperlink.
>   ^O^P  ^Op         *  Search backward for (N-th) OSC8 hyperlink.
>   ^O^L  ^Ol            Jump to the currently selected OSC8 hyperlink.
>
> And prepared mdoc manuals can now display on a normal Unix
> terminal in a normal (actively OSC-8 supporting $PAGER) a TOC (at
> will, with links), and have external (man:, but also http: etc;
> man is built into less(1) -- yay!) links, too.
> For example here ∞ is an external, and † are internal links:
>
>    The OpenSSL program ciphers(1)∞ should be referred to when creating a
>    custom cipher list.  Variables of interest for TLS in general are
>    tls-ca-dir†, tls-ca-file†, tls-ca-flags†, tls-ca-no-defaults†,
>    tls-config-file†, tls-config-module†, tls-config-pairs
>
> So ^O^L on that ciphers(1) opens a new man(1)ual instance.
> For all this functionality a program with 221K bytes is small:
>
>   221360 May 18 22:13 ...less*
>
> Also it starts up into interactive mode with --help.
> So you could have "full interactivity" and colours and mouse, and
> configurability to a large extend, which somehow has to be
> documented, in just 221 K bytes.
>
> I give in in that i try to have --help/-h and --long-help/-H, but
> sometimes that -h is only minimal, because a screenful of data is
> simply not enough to allow users to have a notion.
>
> So less could split the manual into a less.1 and a less-book.7.
> The same is true for bash, for sure.  (And for my little mailer.)
> But things tend to divert, and it is hard enough to keep one
> manual in sync with the codebase, especially if you develop
> focused and expert-idiotized in a one man show.
>
>  |What prompted me to look was another disheartening discovery. The "small
>  |special tool" Gnu diff has a 95-page manual!  And it doesn't cover the
>  |option I was looking up (-h). To be fair, the manual includes related
>  |programs like diff3(1), sdiff(1) and patch(1), but the original manual
> for
>  |each fit on one page.
>  --End of <CAKH6PiXaYGEUmVFRX99eM6s3+nTJrbVvkuBRa-Awhhd69xzJrg@mail.gmail\
>  .com>
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>

[-- Attachment #2: Type: text/html, Size: 6358 bytes --]

  reply	other threads:[~2024-05-19  8:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-18 18:07 Douglas McIlroy
2024-05-18 18:13 ` Brantley Coile
2024-05-18 18:18 ` Larry McVoy
2024-05-18 18:52   ` Clem Cole
2024-05-18 19:19     ` Luther Johnson
2024-05-18 20:12       ` segaloco via TUHS
2024-05-18 19:32     ` Stuff Received
2024-05-18 18:22 ` Ralph Corderoy
2024-05-19  8:58   ` [TUHS] The 'usage: ...' message. (Was: On Bloat...) Ralph Corderoy
2024-05-18 18:31 ` [TUHS] Re: On Bloat and the Idea of Small Specialized Tools Peter Weinberger (温博格) via TUHS
2024-05-18 20:33 ` Steffen Nurpmeso
2024-05-19  8:39   ` Marc Rochkind [this message]
2024-05-20  6:07     ` Adam Thornton
2024-05-20 15:43       ` [TUHS] Documentation (was On Bloat and the Idea of Small Specialized Tools) Paul Winalski
2024-05-20 16:37         ` [TUHS] " Andrew Hume
2024-05-20 18:38         ` Yeechang Lee
2024-05-20 19:27           ` Phil Budne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOkr1zUeW9cMt=Dk+bXbRtCkh=m7bZtkKNaqO8zF43kxt6V+ww@mail.gmail.com' \
    --to=mrochkind@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).