Re: [TUHS] Proliferation of options is great simplification of pipes, really?

[Jon Steinhart <jon@fourwinds.com>]

Will Senn writes:
> This is a multi-part message in MIME format.
>
> All,
>
> So, we've been talking low-level design for a while. I thought I would 
> ask a fundamental question. In days of old, we built small 
> single-purpose utilities and used pipes to pipeline the data and 
> transformations. Even back in the day, it seemed that there was tension 
> to add yet another option to every utility. Today, as I was marveling at 
> groff's abilities with regard to printing my man pages directly to my 
> printer in 2021, I read the groff(1) page:
>
> example here: https://linux.die.net/man/1/groff
>
> What struck me (the wrong way) was the second paragraph of the description:
>
> The groff program allows to control the whole groff system by command 
> line options. This is a great simplification in comparison to the 
> classical case (which uses pipes only).
>
> Here is the current plethora of options:
> groff [-abcegilpstzCEGNRSUVXZ] [-d cs] [-f fam] [-F dir] [-I dir] [-L 
> arg] [-m name] [-M dir] [-n num] [-o list] [-P arg] [-r cn] [-T dev] [-w 
> name] [-W name] [file ...]
>
> Now, I appreciate groff, don't get me wrong, but my sensibilities were 
> offended by the idea that a kazillion options was in any way simpler 
> than pipelining single-purpose utilities. What say you? Is this the 
> perfected logical extension of the unix pioneers' work, or have we gone 
> horribly off the trail.
>
> Regards,
>
> Will

I'm 99% happy with groff and its many options.  Why?  Because the various
programs (troff, pic, tbl, eqn, ...) are still available and can be composed
into pipelines of my own choosing.  The 1% unhappiness is because I think
that groff should be a shell script which it doesn't appear to be.  In my
opinion, if groff was a bad thing then one would have to question things
like scripts and aliases in general.  Groff is a composer, and composability
is a core UNIXism to me.  It would be way wrong if it replaced all of the
programs that it invoked, but it doesn't.

As an interesting example of the composability of the troff system, I did
the diagrams for my book using pic because pic is awesome.  But, despite
what it says in the No Starch Press author guidelines, they really only
accept material in word format.  I could have rendered each image as a
bitmap, but that just seemed so 80s.  Turns out that while it doesn't do
a great job, word will accept vector graphics in SVG format.  So I ran
each image through pic, through groff, through ps2pdf (embedding fonts),
through pdf2svg, and finally through inkscape to crop the image.  A tad
cumbersome, but it works, and wouldn't be easy to do on any other system.

I also did my original draft in troff and wrote a script to convert it
into openoffice XML format so that it could be word-ified.  Only part
that I couldn't figure out was how to include the figures; I could
generate the XML but it didn't work and there were no useful diagnostics
so I had to import them by hand.

Since Rob is on the list and (in)famous for the "cat -v" argument, I would
agree with him that that is not the "right" way.  Being consistent with
my position on groff, I would go for a separate show-nonprinting utility
and then, if widely used, a script that composed that and cat.

Jon