[COFF] On Bloat and the Idea of Small Specialized Tools

[COFF] On Bloat and the Idea of Small Specialized Tools

[Clem Cole]

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

While the idea of small tools that do one job well is the core tenant of
what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I
have moved this discussion to COFF and BCCing TUHS for now.

The key is that not all "bloat" is the same (really)—or maybe one person's
bloat is another person's preference.  That said, NIH leads to pure bloat
with little to recommend it, while multiple offerings are a choice. Maybe
the difference between the two may be one person's view over another.

On Fri, May 10, 2024 at 6:08 AM Rob Pike <robpike@gmail.com> wrote:

> Didn't recognize the command, looked it up. Sigh.
>
Like Rob -- this was a new one for me, too.
I looked, and it is on the SYS3 tape; see:
https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man1/nl.1


>   pr -tn <file>
>

> seems sufficient for me, but then that raises the question of your
> question.
>
Agreed, that has been burned into the ROMs in my  fingers since the
mid-1970s 😀
BTW: SYS3 has pr(1) with both switches too  (more in a minute)


> I've been developing a theory about how the existence of something leads
> to things being added to it that you didn't need at all and only thought of
> when the original thing was created.
>
That is a good point, and I generally agree with you.


> Bloat by example, if you will. I suspect it will not be a popular theory,
> however accurately it may describe the technological world.
>

Of course, sometimes the new features >>are<< easier (more natural *for
some people*).  And herein lies the core problem. The bloat is often
repetitive, and I suggest that it is often implemented in the wrong place -
and usually for the wrong reasons.

Bloat comes about because somebody thinks they need some feature and
probably doesn't understand that it is already there or how they can use
it. But they do know about it, their tool must be set up to exploit it - so
they do not need to reinvent it.  GUI-based tools are notorious for this
failure. Everyone seems to have a built-in (unique) editor, or a private
way to set up configuration options et al. But ... that walled garden is
comfortable for many users and >>can be<< useful sometimes.

Long ago, UNIX programmers learned that looking for $EDITOR in the
environment was way better than creating one.  Configuration was as ASCII
text, stored in /etc for system-wide and dot files in the home for users.
But it also means the >>output<< of each tool needs to be usable by each
other [*i.e.*, docx or xlx files are a no-no).

For example, for many things on my Mac, I do use the GUI-based tools --
there is no doubt they are better integrated with the core Mac system >>for
some tasks.<< But only if I obey a set of rules Apple decrees.  For
instance, this email read is easier much of the time than MH (or the HM
front end, for that matter), which I used for probably 25-30 years. But on
my Mac, I always have 4 or 5 iterm2(1) open running zsh(1) these days. And,
much of my typing (and everything I do as a programmer) is done in the shell
(including a simple text editor, not an 'IDE').  People who love IDEs swear
by them -- I'm just not impressed - there is nothing they do for me that
makes it easier, and I have learned yet another scheme.

That said, sadly, Apple is forcing me to learn yet another debugger since
none of the traditional UNIX-based ones still work on the M1-based systems.
But at least LLDB is in the same key as sdb/dbx/gdb *et al*., so it is a
PITA but not a huge thing as, in the end, LLDB is still based on the UNIX
idea of a single well-designed and specific to the task tool, to do each
job and can work with each other.

FWIW: I was recently a tad gob-smacked by the core idea of UNIX and its
tools, which I have taken for a fact since the 1970s.

It turns out that I've been helping with the PiDP-10 users (all of the
PiDPs are cool, BTW). Before I saw UNIX, I was paid to program a PDP-10. In
fact, my first UNIX job was helping move programs from the 10 to the UNIX.
Thus ... I had been thinking that doing a little PDP-10 hacking shouldn't
be too hard to dust off some of that old knowledge.  While some of it has,
of course, come back.  But daily, I am discovering small things that are so
natural with a few simple tools can be hard on those systems.

I am realizing (rediscovering) that the "build it into my tool" was the
norm in those days.   So instead of a pr(1) command, there was a tool that
created output to the lineprinter. You give it a file, and it is its job to
figure out what to do with it, so it has its set of features (switches) -
so "bloat" is that each tool (like many current GUI tools) has private ways
of doing things. If the maker of tool X decided to support some idea, they
would do it like tool Y.  The problem, of course, was that tools X and Y
had to 'know about' each type of file (in IBM terms, use its "access
method").  Yes, the engineers at DEC, in their wisdom, tried to
"standardize" those access methods/switches/features >>if you implemented
them<< -- but they are not all there.

This leads me back to the question Rob raises.  Years ago, I got into an
argument with Dave Cutler RE: UNIX *vs.* VMS. Dave's #1 complaint about
UNIX in those days was that it was not "standardized."  Every program was
different, and more to Dave's point, there was no attempt to make switches
or errors the same [getopt(3) had been introduced but was not being used by
most applications).  He hated that tar/tp used "keys" and tools like cpio
used switches.  Dave hated that I/O was so simple - in his world all user
programs should use his RMS access method of course [1].  VMS, TOPS, *etc.*,
tried to maintain a system-wide error scheme, and users could look things
like errors up in a system DB by error number, *etc*.  Simply put, VMS is
very "top-down."

My point with Dave was that by being "bottom-up," the best ideas in  UNIX
were able to rise. And yes, it did mean some rough edges and repeated
implementations of the same idea.  But UNIX offered a choice, and while Rob
and I like and find: pr -tn perfectly acceptable thank you, clearly someone
else desired the features that nl provides. The folks that put together
System 3 offer both solutions and let the user choose.

This, of course, comes as bloat, but maybe that is a type of bloat so bad?


My own thinking is this - get things down to the basics and simplest
privatives and then build back up.  It's okay to offer choices, as long as
the foundation is simple and clean.  To me, bloat becomes an issue when you
do the same thing over and over again, particularly because you can not
utilize what is there already, the worst example is NIH - which happens way
more than it should.


I think the kind of bloat that GUI tools and TOPS et al. created forces
recreation, not reuse. But offering choice and the expense of multiple
tools that do the same things strikes me as reasonable/probably a good
thing.


1.]  BTW: One of my favorite DEC stories WRT to VMS engineering has to do
with the RMS I/O system.  Supporting C using VMS was a bit of PITA.
 Eventually, the VMS engineers added Stream I/O - which simplified the C
runtime, but it was also made available for all technical languages.
Fairly soon after it was released, the DEC Marketing folks discovered
almost all new programs, regardless of language, had started to use Stream
I/O and many older programs were being rewritten by customers to use it. In
fact, inside of DEC itself, the languages group eventually rewrote things
like the FTN runtime to use streams, making it much smaller/easier to
maintain.   My line in the old days: "It's not so bad that ever I/O has
offer 1000 options, it's that Dave to check each one for every I/O. It's a
classic example of how you can easily build RMS I/O out of stream-based
I/O, but the other way around is much harder.   My point here is to *use
the right primitives*. RMS may have made it easier to build RDB, but it
impeded everything else.

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

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Steffen Nurpmeso]

Clem Cole wrote in
 <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>:
 |While the idea of small tools that do one job well is the core tenant of
 |what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I
 |have moved this discussion to COFF and BCCing TUHS for now.
 |
 |The key is that not all "bloat" is the same (really)—or maybe one person's
 |bloat is another person's preference.  That said, NIH leads to pure bloat

Yeah, give me back my "cat -vet"!

 |with little to recommend it, while multiple offerings are a choice. Maybe
 |the difference between the two may be one person's view over another.

Sure.  Many of the small Unix tools are simply unknown to many
newcomers (like myself), or they turn out to be too simple, pr has
always been enscript here, for example.  I wonder how many modern
Linux systems even ship the majority of these tools, or how often
they get invoked, if at all.

But deep in my heart i dislike the systemd that totally
contradicts the entire concept as such, and hope i can stick to my
fast and simple booting with SysV scripts, and separate daemons
for separate tasks.

  ...[dropped the top-posted stuff]

--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)

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Ralph Corderoy]

Hi Steffen,

> pr has always been enscript here, for example.

enscript turns text into PostScript.  That's not too handy to read.
pr's output doesn't have to be sent to a printer.  I doubt there's
a week goes by without my using it.  It just depends what your fingers
know.

-- 
Cheers, Ralph.

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Steffen Nurpmeso]

Ralph Corderoy wrote in
 <20240511091822.B6691215AA@orac.inputplus.co.uk>:
 |Hi Steffen,
 |
 |> pr has always been enscript here, for example.
 |
 |enscript turns text into PostScript.  That's not too handy to read.
 |pr's output doesn't have to be sent to a printer.  I doubt there's
 |a week goes by without my using it.  It just depends what your fingers
 |know.

Nah, it can create text too (with control sequences, but that you
can filter away again, and mostly there are none, anyway).
I am actually not using it no more that often; i used it often to
review (80 column) code via printout, and it can/could give you
8 pages on a single DIN A4 paper.  (Or two times 4 pages, to be
more exact.)

--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)

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Larry McVoy]

On Sat, May 11, 2024 at 11:18:43PM +0200, Steffen Nurpmeso wrote:
> Ralph Corderoy wrote in
>  <20240511091822.B6691215AA@orac.inputplus.co.uk>:
>  |Hi Steffen,
>  |
>  |> pr has always been enscript here, for example.
>  |
>  |enscript turns text into PostScript.  That's not too handy to read.
>  |pr's output doesn't have to be sent to a printer.  I doubt there's
>  |a week goes by without my using it.  It just depends what your fingers
>  |know.
> 
> Nah, it can create text too (with control sequences, but that you
> can filter away again, and mostly there are none, anyway).
> I am actually not using it no more that often; i used it often to
> review (80 column) code via printout, and it can/could give you
> 8 pages on a single DIN A4 paper.  (Or two times 4 pages, to be
> more exact.)

Wow, that brings back memories.  Let me look.  Yeah here it is.  
Prints 8 pages per page from postscript.  Pretty sure I wrote it,
it looks like my style.  But 100% sure it was useful when my eyesight
was better :-)

#!/usr/bin/perl -w

open(STDOUT, "|mpage -a -P- -8");
# Print the starting stuff
while (<>) {
	print;
	last if /%%EndProlog/;
}

$base = "/tmp/psrev";
$page = 1;

# Save each page from 
#	%%Page to the next in a file
$_ = <>;
while ($_ && !/%%Trailer/) {
	$file = $base . $page++;
	#warn "Creating $file\n";
	open(OUT, ">$file");
	do {
		print OUT;
		$_ = <>;
	} while ($_ && !/%%Page/ && !/%%Trailer/);
	close(OUT);
}

# Take each 8 and print them in the right order
$here = 0;
while ($here < $page - 8) {
	foreach $i (2,4,6,8,1,3,5,7) {
		&show($here + $i);
	}
	$here += 8;
}

# One page left.
if ($here == $page - 2) {
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
}
# Two pages left
if ($here == $page - 3) {
	&show($here + 2);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
}
# Three pages left
if ($here == $page - 4) {
	&show($here + 2);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	&show($here + 3);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
}
# Four pages left
if ($here == $page - 5) {
	&show($here + 2);
	&show($here + 4);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	&show($here + 3);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
}
# Five pages left
if ($here == $page - 6) {
	&show($here + 2);
	&show($here + 4);
	print "%%Page: 0 0\nshowpage\n";
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	&show($here + 3);
	&show($here + 5);
	print "%%Page: 0 0\nshowpage\n";
}
# Six pages left
if ($here == $page - 7) {
	&show($here + 2);
	&show($here + 4);
	&show($here + 6);
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	&show($here + 3);
	&show($here + 5);
	print "%%Page: 0 0\nshowpage\n";
}
# Seven pages left
# foreach $i (2,4,6,8,1,3,5,7) {
if ($here == $page - 8) {
	&show($here + 2);
	&show($here + 4);
	&show($here + 6);
	print "%%Page: 0 0\nshowpage\n";
	&show($here + 1);
	&show($here + 3);
	&show($here + 5);
	&show($here + 7);
}

if ($_) {
	do {
		print;
	} while (defined($_ = <>));
}
exit;


sub show
{
	local($p) = $_[0];

	$file = $base . $p;
	if (-e $file) {
		#warn "Doing $file\n";
		open(IN, $file);
		while (defined($line = <IN>)) {
			print $line;
		}
		unlink($file);
	}
}

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Nevin Liber]

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

On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc@ccc.com> wrote:

> The key is that not all "bloat" is the same (really)—or maybe one person's
> bloat is another person's preference.
>

A lot of "bloat" comes because our systems really aren't focused on
"discoverability".

While I probably have used "pr" in the past, I've totally forgotten, the
name "pr" doesn't really help me understand what it is for, and it's just
one of 982 files in my /usr/bin directory alone.  How does one discover it?

It's like using "sed" instead of "head": sure, if you already know "sed",
you don't need "head", but for English speaking folks who know "tail" is
there, it would be (and was in the old days) surprising and frustrating not
to have "head".

If I have a command and I want it to do something slightly different, the
first place I look is to see if there is a command line option for that.  I
know how to discover that (either --help or the man pages).

GUIs were better at discoverability.  The menu at the top made it easy to
see (and constantly reinforced) what was possible, at least until we got
into the era of contextual menus, gestures and force presses.

They aren't perfect.  I get plenty of dialog boxes which have a check box
for "Do not show this message again" which I don't dare check, because I
don't know how to bring up whatever choice it wants me to decide on should
I need to change it in the future.


And once you have users/customers, it's hard to get rid of things, because
they value stability.
-- 
 Nevin ":-)" Liber  <mailto:nl <nevin@eviloverlord.com>iber@gmail.com>
+1-847-691-1404

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

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Ralph Corderoy]

Hi Nevin,

> the name "pr" doesn't really help me understand what it is for

As typical of the early commands, it's readily mnemonic.

    PR(I)                      3/20/74                       PR(I)

    NAME
        pr - print file

    SYNOPSIS
        pr [-h header] [-n] [+n] [-wn] [-ln] [-t] [name...]

> How does one discover it?

Back then, by reading through the permuted index, turning the pages of
the printed manual, word of mouth...  By making effort to learn the
profession's tools.

> If I have a command and I want it to do something slightly different,
> the first place I look is to see if there is a command line option for
> that.  I know how to discover that (either --help or the man pages).

And a fine man page's SEE ALSO may help learn of new commands.

-- 
Cheers, Ralph.

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[John P. Linderman]

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

Marc Rochkind used to advise reading the entire UNIX manual cover to cover
each year. The manual was short enough that it could be done in a day or
two. It was a great way to discover commands and system calls you didn't
use every day, and deepen your understanding of the ones you did use every
day. We were in a center that ran PWB UNIX, and the manual was overseen by
Ted Dolotta, who was a stickler for good writing. I can't imagine trying to
do something similar now. -- jpl

On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:

> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc@ccc.com> wrote:
>
>> The key is that not all "bloat" is the same (really)—or maybe one
>> person's bloat is another person's preference.
>>
>
> A lot of "bloat" comes because our systems really aren't focused on
> "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the
> name "pr" doesn't really help me understand what it is for, and it's just
> one of 982 files in my /usr/bin directory alone.  How does one discover it?
>
> It's like using "sed" instead of "head": sure, if you already know "sed",
> you don't need "head", but for English speaking folks who know "tail" is
> there, it would be (and was in the old days) surprising and frustrating not
> to have "head".
>
> If I have a command and I want it to do something slightly different, the
> first place I look is to see if there is a command line option for that.  I
> know how to discover that (either --help or the man pages).
>
> GUIs were better at discoverability.  The menu at the top made it easy to
> see (and constantly reinforced) what was possible, at least until we got
> into the era of contextual menus, gestures and force presses.
>
> They aren't perfect.  I get plenty of dialog boxes which have a check box
> for "Do not show this message again" which I don't dare check, because I
> don't know how to bring up whatever choice it wants me to decide on should
> I need to change it in the future.
>
>
> And once you have users/customers, it's hard to get rid of things, because
> they value stability.
> --
>  Nevin ":-)" Liber  <mailto:nl <nevin@eviloverlord.com>iber@gmail.com>
> +1-847-691-1404
>

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

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Dan Cross]

On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:
> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc@ccc.com> wrote:
>> The key is that not all "bloat" is the same (really)—or maybe one person's bloat is another person's preference.
>
> A lot of "bloat" comes because our systems really aren't focused on "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone.  How does one discover it?

This is a fantastic question. At one point, I went through every
command in /bin and /usr/bin and figured out what it did. That was a
tremendously useful exercise, but that was in the days when the total
number of commands in those directories numbered in the low hundreds;
982 is a lot.

`pr` is an interesting case in point. I would guess that the name
comes from Multics, where `print` (short name `pr`) is sort of the
equivalent of `cat`, but contains a lot of extra functionality to
control output, read archives, etc. But if one has never used Multics
(and let's be honest: the total number of people in the world who have
done so is a tiny, tiny fraction of the number of computer users), one
would never guess that. When I started using Unix, I thought that "pr"
was how you sent a file to the printer; "lpr" was highly
non-intuitive, but I'd never seen a line printer at that point (our
first home computer was a Mac with an imagewriter); the idea of
`cat`ing a file into the printer device wasn't something I'd ever even
considered (besides, I think the device was owned and writable only as
root).

> It's like using "sed" instead of "head": sure, if you already know "sed", you don't need "head", but for English speaking folks who know "tail" is there, it would be (and was in the old days) surprising and frustrating not to have "head".

I don't know if this is an argument about bloat per se, but rather
about system design generally. Sure, `sed 10q` does more or less what
`head` does, but that's not a great argument for `head` not existing.
After all, assembler can do everything that C can, and yet given a
choice between the two, for most programs I'd prefer the latter.

> If I have a command and I want it to do something slightly different, the first place I look is to see if there is a command line option for that.  I know how to discover that (either --help or the man pages).
>
> GUIs were better at discoverability.  The menu at the top made it easy to see (and constantly reinforced) what was possible, at least until we got into the era of contextual menus, gestures and force presses.
>
> They aren't perfect.  I get plenty of dialog boxes which have a check box for "Do not show this message again" which I don't dare check, because I don't know how to bring up whatever choice it wants me to decide on should I need to change it in the future.
>
> And once you have users/customers, it's hard to get rid of things, because they value stability.

Absolutely.

        - Dan C.

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Bakul Shah via COFF]

On May 11, 2024, at 6:12 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:
>> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc@ccc.com> wrote:
>>> The key is that not all "bloat" is the same (really)—or maybe one person's bloat is another person's preference.
>> 
>> A lot of "bloat" comes because our systems really aren't focused on "discoverability".
>> 
>> While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone.  How does one discover it?
> 
> This is a fantastic question. At one point, I went through every
> command in /bin and /usr/bin and figured out what it did. That was a
> tremendously useful exercise, but that was in the days when the total
> number of commands in those directories numbered in the low hundreds;
> 982 is a lot.

I did this when I first encountered Unix (v7): tried out most things
described in every command's man page! I still occasionally scan the
the [s]bin directories. But it seems there are fewer and fewer new
programs that can be used in cmd pipelines. The situation is a bit
like Sanskrit (built from a relatively small set of root words but
infinitely combinable) and prakrits, vernacular dialects that are
not so flexible but more practical.

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Grant Taylor via COFF]

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

On 5/11/24 08:12, Dan Cross wrote:
> `pr` is an interesting case in point. I would guess that the name comes 
> from Multics, where `print` (short name `pr`) is sort of the equivalent 
> of `cat`, but contains a lot of extra functionality to control output, 
> read archives, etc. But if one has never used Multics (and let's be 
> honest: the total number of people in the world who have done so is a 
> tiny, tiny fraction of the number of computer users), one would never 
> guess that. When I started using Unix, I thought that "pr" was how 
> you sent a file to the printer; "lpr" was highly non-intuitive, but 
> I'd never seen a line printer at that point (our first home computer 
> was a Mac with an imagewriter); the idea of `cat`ing a file into the 
> printer device wasn't something I'd ever even considered (besides, 
> I think the device was owned and writable only as root).

It wasn't until this thread that I became aware of `pr` as I've been an 
`nl` user for years.

It wasn't until the message that I'm replying to that I realized the 
naming relation between `pr` and `lpr`.

I also wonder if `pr` makes more sense in the context of teletypes 
wherein when you `pr`(int) a file, you end up with a printout on the 
teletype that you're using.  Conversely `lpr` would send something to 
the line printer elsewhere.

It makes sense in my head.

I have no idea if it's accurate or not.



-- 
Grant. . . .

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Ralph Corderoy]

Hi,

> It wasn't until this thread that I became aware of `pr` as I've been
> an `nl` user for years.

Learning of pr can also be done by reading Kernighan and Plauger's
‘Software tools’.  There, it's called print and is more basic but
a variety of enhancements are listed.  They then write:

    When you write a program, there is a great temptation to add more
    and more ‘features’ like these, little things that it will do for
    you.  But beware -- unless the features work together in a uniform
    way, the result is going to be a grab-bag of unrelated capabilities,
    most of which won't get used because nobody can remember them.
    If you have to look up how to use a program for even the simplest
    applications, you know you've gone too far.  When in doubt, treat
    ‘feature’ as a pejorative.  (Think of a hundred-bladed Swiss army
    knife.)

>From memory, I think all of the significant programs written in that
book have an early Unix ancestor.

-- 
Cheers, Ralph.

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Theodore Ts'o]

On Sat, May 11, 2024 at 09:12:33AM -0400, Dan Cross wrote:
> On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:
> > A lot of "bloat" comes because our systems really aren't focused on "discoverability".
> >
> > While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone.  How does one discover it?
> 
> This is a fantastic question. At one point, I went through every
> command in /bin and /usr/bin and figured out what it did. That was a
> tremendously useful exercise, but that was in the days when the total
> number of commands in those directories numbered in the low hundreds;
> 982 is a lot.

Yeah, I think that a lot of this goes back to scalability.  What might
work well in the simpler world of V7 Unix might be more challenging
probem space today.  One example of this is how many people got
started with Kernel programming.  When I first started working on
Linux, which was back in 1991, I could print out all of the kernel
source (heh, using "enscrpt -2rGh") and that was less than an inch
think of paper, and I could read it all.  I'm sure people had done
similar things with the Unix source code, or via the underground
photocopied of the Lyons book (AT&T copyright be d*mned :-).  But
today, that's really not a practical way for people to get started
with Unix/Linux systems programming.

Another example of this is if you want to do something with more
complex data than just plain text files with fixed data fields that
you could manipulate using sort, awk, and Unix pipes.  What if you
>need more complex structured data, stored say in JSON?  Sure, you can
do something with pipes and jq.  So sure, I can do something that is
more true to the Unix philosphy like this:

	    gcloud compute instances describe \
			--zone "$z" "$i" --format=json > "$inst_info"
	    kver=$(jq < "$inst_info" 2> /dev/null \
		'.metadata.items[] | select(.key == "kernel_version") | .value' | \
			sed -e 's/^"//' -e 's/"$//' \
			    -e 's/^Linux xfstests-[0-9A-Za-z-]* //' -e 's/ .*//')
`	    gce_status=$(jq < "$inst_info" .status | \
			    sed -e 's/^"//' -e 's/"$//')
	    status=$(jq < "$inst_info" 2> /dev/null \
		'.metadata.items[] | select(.key == "status") | .value' | \
			    sed -e 's/^"//' -e 's/"$//')
	    ip=$(jq < "$inst_info" 2> /dev/null \
		    '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' | \
			sed -e 's/^"//' -e 's/"$//')


...  but arguably, this is at the limit at what you can do using Unix
pipes as opposed to using Perl or Python.... but commands like:

	jq '.metadata.items[] | select(.key == "kernel_version") | .value'

is doing a huge amount of the heavy lifting.

I bet most of the young'uns would not be trying to do this as a shell
script, but using the Cloud SDK with perl or python or Go, which is
*way* more bloaty than using /bin/sh.

So while some of us old farts might be bemoaning the death of the Unix
philosophy, perhaps part of the reality is that the Unix philosophy
were ideal for a simpler time, but might not be as good of a fit
today.

Cheers,

     	      		       	     - Ted

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Gergely Buday]

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

Theodore Ts'o <tytso@mit.edu> ezt írta (időpont: 2024. máj. 11., Szo 22:35):

>
>
> So while some of us old farts might be bemoaning the death of the Unix
> philosophy, perhaps part of the reality is that the Unix philosophy
> were ideal for a simpler time, but might not be as good of a fit
> today.


These days functional programmers follow the idea of writing small
functions and combine them in interesting ways.

- Gergely

>

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

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Ralph Corderoy]

Hi,

As an example of pushing the limit of Unix pipes, I found this awkward
to read, e.g. the noise of the redundant backslash after an end-of-line
pipe.

>             gcloud compute instances describe \
>                         --zone "$z" "$i" --format=json > "$inst_info"
>             kver=$(jq < "$inst_info" 2> /dev/null \
>                 '.metadata.items[] | select(.key == "kernel_version") | .value' | \
>                         sed -e 's/^"//' -e 's/"$//' \
>                             -e 's/^Linux xfstests-[0-9A-Za-z-]* //' -e 's/ .*//')
> `           gce_status=$(jq < "$inst_info" .status | \
>                             sed -e 's/^"//' -e 's/"$//')
>             status=$(jq < "$inst_info" 2> /dev/null \
>                 '.metadata.items[] | select(.key == "status") | .value' | \
>                             sed -e 's/^"//' -e 's/"$//')
>             ip=$(jq < "$inst_info" 2> /dev/null \
>                     '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' | \
>                         sed -e 's/^"//' -e 's/"$//')

Re-formatting, including the more idiomatic placement of I/O
redirection, gives

    gcloud compute instances describe \
        --zone "$z" "$i" --format=json >"$inst_info"

    kver=$(
        jq '.metadata.items[] | select(.key == "kernel_version") | .value' \
            <"$inst_info" 2>/dev/null |
        sed '
                s/^"//; s/"$//
                s/^Linux xfstests-[0-9A-Za-z-]* //
                s/ .*//
            '
    )
    gce_status=$(
        jq .status \
            <"$inst_info" |
        sed 's/^"//; s/"$//'
    )
    status=$(
        jq '.metadata.items[] | select(.key == "status") | .value' \
            <"$inst_info" 2>/dev/null |
        sed 's/^"//; s/"$//'
    )
    ip=$(
        jq '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' \
            <"$inst_info" 2>/dev/null |
        sed 's/^"//; s/"$//'
    )

The repetition is now more clear to me.  And I see jq's stderr is
discarded in all but one case.  Assuming that one can be, or should be,
the same allows factoring.

    gcloud compute instances describe \
        --zone "$z" "$i" --format=json >"$inst_info"

    query() {
        jq "${1?}" <"$inst_info" 2>/dev/null |
        sed 's/^"//; s/"$//'
    }

    kver=$(
        query '.metadata.items[] | select(.key == "kernel_version") | .value' |
        sed 's/^Linux xfstests-[0-9A-Za-z-]* //; s/ .*//'
    )
    gce_status=$(query .status)
    status=$(query '.metadata.items[] | select(.key == "status") | .value')
    ip=$(query '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP')

-- 
Cheers, Ralph.

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Dave Horsfall]

On Sun, 12 May 2024, Ralph Corderoy wrote:

> As an example of pushing the limit of Unix pipes, I found this awkward 
> to read, e.g. the noise of the redundant backslash after an end-of-line 
> pipe.

Y'know, I've been writing "| \" for donkeys' (well, "^ \" early in the 
game), and I never knew...

I suppose I could write a Perl script to modify them.

-- Dave

[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

[Clem Cole]

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

On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:

> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc@ccc.com> wrote:
>
>> The key is that not all "bloat" is the same (really)—or maybe one
>> person's bloat is another person's preference.
>>
>
> A lot of "bloat" comes because our systems really aren't focused on
> "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the
> name "pr" doesn't really help me understand what it is for, and it's just
> one of 982 files in my /usr/bin directory alone.  How does one discover it?
>
Chapter 1, Page 15 of Kernigahan and Pike -- "The Unix Programming
Environment"

It's still the best book for learning, regardless if Linux is your
preferred UNIX implementation.


>
> It's like using "sed" instead of "head": sure, if you already know "sed",
> you don't need "head", but for English speaking folks who know "tail" is
> there, it would be (and was in the old days) surprising and frustrating not
> to have "head".
>
Hmmm..  date on 1BSD tape for head is Nov 23, 1977.  It's been around since
the Sixth Edition.
And again - this is my observation - some tools are easier to use, and the
head is easier than a sed script.  One can argue a shell script that exec's
sed for you would have been sufficient to Joy's program.
However, in wnj's defense, he wrote it for sed was not part of the Sixth
Edition.

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

[COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Arno Griffioen via COFF]

On Fri, May 10, 2024 at 06:22:15PM -0500, Nevin Liber wrote:
> GUIs were better at discoverability.  The menu at the top made it easy to see
> (and constantly reinforced) what was possible, at least until we got into the
> era of contextual menus, gestures and force presses.

At the risk of really sounding like a grumpy old fart... This in spades..

I have to laugh whenever there's a new iPhone/Android/Home-automation/Car
or other 'touchscreen' device out and these days it seems required to watch 
about a dozen Youtube video's before you even know what new 
tap/touch/button/squeeze action you can or have to do now to access some 
feature.

Supposedly we didn't want CLI's anymore because they were 'not intuitive' and
'hard to access for lay persons'. (fair ciriticism..)

... and now we have these devices that often show a pretty picture, but *no* 
outward sign or indication about possible inputs/actions you can perform. 

It's.. Almost like it's getting as bad as a '$ ' prompt for the 'uninitiated'

For fun, give a heavy iPhone user an Android phone or vice-versa and see
smoke coming out of their ears as they fight with it..  :)

							Bye, Arno.