[Toybox] Thoughts on seperating shell dependencies and MAYFORK commands?

[Mouse]

>> I'm not a routine toybox user.  But, to the extent that toybox tries
>> to be general-purpose, perhaps some comments from general-purpose
>> shell use are relevant here.
> "Not a question, more of a comment."

Exactly.

>>> There used to be a blog that handed out the "unnecessary use of
>>> cat" award, because redirects are cheaper.
>> When they work.  I never investigated enough to be in a position to
>> say anything definite, but I've seen occasional (emphasis on
>> "occasional") cases where cat THING | ... works, but < THING ...
>> doesn't.  Maybe all such cases represent bugs?  Not sure.
> You didn't give enough information for me to guess why you couldn't
> get it to work.

No, of course not.  Nor did I intend to, because I don't have enough
information, and you are highly unlikely to be using the same software
I was using at the time anyway.

That was not a report for you to investigate but more a warning against
assuming that "cat THING | ..." and "< THING ..." are necessarily
equivalent.  They are in most cases, yes, but most != all.

Perhaps toybox considers it a bug, to be fixed, for them to differ; in
that case, it's more reasonable to perform that transformation (though
I still don't like it, as I mentioned further down, in text that's not
making it into this email).

>> I've also (though less often) had cases where I don't want to wait
>> for the whole list to be computed before getting working on the
>> first few items.
> It is often possible to rewrite a "fast on single processor when all
> data is immediately available" thing for more parallelism or
> progressive processing of gradually delivered input, yes.

My cases are more often things like "search filesystem for certain
things, looking for one with a certain property" when that property is
common enough among the objects in question that one will likely be
found before getting very far into the list, but the filesystem search
produces list items at a slow enough rate that processing them as
they're found finds the desired hit faster than batching will.

Come to think of it, that's another option I could add to mxa: don't
block waiting for input unless there are no arguments pending.

> Which gnu/less keeps breaking again every few years:

>   $ while sleep .5; do echo -n .; done | less

You don't say what it is that that does that you consider broken.  I'm
going to guess that the behaviour in question is less's failure to
update its displays as the dots come in.

I'm not sure I would expect that to behave otherwise, regardless of
GNU; I _think_ every version of less I've ever used does that.  The
version of less I carry around with me (I do that to get predictable
behaviour) has Mark Nudelman two-clause BSD copyright licenses, and
nothing else, and thus I feel moderately confident it has nothing to do
with GNU.  But as far as I can see it behaves the same as /usr/bin/less
on an Ubuntu 22.04.3 LTS work machine I have access to in that regard.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B