[Toybox] interesting new (?) env(1) options

[Rob Landley]

On 3/15/24 17:48, enh wrote:
> 
> 
> On Fri, Mar 15, 2024 at 3:43 PM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 3/15/24 16:27, enh wrote:
>     >     That said, I'm not implementing --longopts without a short opt until
>     somebody
>     >     comes to me with a use case. And then I would come up with short
>     options. Also,
>     >     "env" is probably the wrong place to put this unless it's also going
>     to sprout
>     >     flags to change niceness level and so on: man 7 signal and man 7
>     environ are
>     >     different pages.
>     >
>     > i know what you mean, but at the same time, the fact that this swiss army
>     knife
>     > doesn't actually exist is a bug in its own right.
> 
>     A swiss army knife tool is not unix. Unix is "do one thing and do it well", and
>     then combine them either with pipes or via:
> 
>       nice -n 20 env -i potato=wombat nohup nsenter -m chroot thingy /bin/blah
> 
>     Having a "sigfilt -INT +HUP cat /proc/potato" in a list like that doesn't seem
>     like a big lift. (Recycling the "kill" plumbing to understand signal names, and
>     the -block +unblock stuff from shell options, maybe with the magic name ALL
>     being every signal. Seems like it might also want a taskset/chmod style
>     set/unset mask, but I'd want to think about that? Or wait for somebody to
>     actually need it, since +ALL and -ALL seem like the default use cases...)
> 
>     If you were going to extend any of the existing commands above to fiddle with
>     more signals, "nohup" would be the obvious choice, not "env". (Modulo the silly
>     stdin/stdout redirection nohup does.)
> 
>     > i regularly find people who
>     > don't realize which of these things there is/isn't a command for. (because not
>     > only are they separate commands, even the man pages don't generally refer
>     to one
>     > another. because, like you say, in a sense they _don't_ have anything much
>     to do
>     > with one another.)
> 
>     Back in college they had xerox pages with one line summaries of commands, which
>     you could "man command" on the machine for.
> 
> 
> i remember when apropros(1) was useful...
> 
> ~$ apropos nice
> nice: nothing appropriate.
> ~$ 
>  
> :-(

Sadly arpopos requires some silly cron job to create a database, but instead of
adapting that for the invention of package management (so the database got
updated when packages were installed/removed) they left it as a cron job, which
bogged down everybody's systems and got shot in the head when laptops overtook
desktops. (Ooh, I wrote a rant about that long ago, I think laptops outsold
desktops in dollar terms in 2004 and unit volume in 2005, but it's been long
enough I don't remember, and that was pre-twitter and before my website blog, so
the rant with actual reference URLs would have been either on livejournal or
some mailing list...)

That said, there's no real reason NOT to update apropos to work based on job
control. (Modulo rebuilding the whole database each package install was
considered too expensive and nobody ever did a delta version.)

In theory "man man" should tell you to look at "man 1 intro", but for some
INSANE reason that still mentions the existence of "info" files (based on the
gopher protocol) and thus 100% irrelevant as of about 1996.

There SHOULD be a tool to list all available commands with a one line summary
the way "aptitude search ." can show you every debian package in the repository
(which is how I know, piping it to wc, there are 74,750 of them in devuan
botulism, yes I still need to upgrade to diptheria).

In THEORY each man page has a "name" section with a one line description, and
there should be a way to emit them all, but if there's a standard way to do it
without writing a shell script I dunno what it is. I generally just do

  ls /usr/share/man/man[0-8]

Although...

$ for i in 1 2 3 4 5 6 7 8; do for j in /usr/share/man/man$i/*; do man $i $j |
grep -A 1 '^NAME$' | tail -n 1; done; done

That sort of almost works except the output is full of:

troff: <standard input>:330: warning [p 3, 10.8i]: can't break line

warning: file '<standard input>', around line 636:
  table wider than line width

But it turns out the problem is that the man pages directory is FULL OF CRAP. I
mean seriously, what is:

$ ls /usr/share/man/man*/* | grep beta19
/usr/share/man/man3/_build_libcaca-MxUtPZ_libcaca-0.99.beta19_caca_.3caca.gz
/usr/share/man/man3/_build_libcaca-MxUtPZ_libcaca-0.99.beta19_caca_codec_.3caca.gz
/usr/share/man/man3/_build_libcaca-MxUtPZ_libcaca-0.99.beta19_caca_driver_.3caca.gz
/usr/share/man/man3/_build_libcaca-MxUtPZ_libcaca-0.99.beta19_ruby_.3caca.gz

That breaks the rule where the ".section.gz" suffix has the only periods in the
filename...

>     Anyway: if a "toybox cheat sheet" seems like a good thing, we're like 80% of the
>     way there already?
> 
> maybe a toybox apropros(1)?

*shrug* Sure? In theory there's a man command in pending, in practice when I
tried to clean it up other people were making it change out from under me so I
deleted my changes and put it at the end of the todo list. Looks like it hasn't
changed for about 5 years, so maybe I should give it another look at some point...

> (although my `apropos nice` example is a bad one because renice(1) has no
> description.)

It should. (And the one line summary at the time is just "renice process" which
is only marginally helpful.

Sigh, how did that command ever get considered cleaned up when main() { has the
curly bracket on the same line. I suspect this predates "pending"...

Also, it should say PID... instead of ID, except... ah, the -g -u -p arguments
say what kind it is. And the debian one cares about order, which this one does
not. And I don't know how to summarize the -n vs non-n behavior in the usage:
line. Have to think about that...

Ok, renice could use some work. Thanks for the heads up, I've got a tab open for
it now...

Rob