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

[Rob Landley]

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.

For a while https://man7.org/linux/man-pages/dir_section_1.html and friends were
useful but then he dumped 8 zillion unrelated packages into them, reproducing
Yogi Bera's "nobody goes there anymore, it's too crowded". (I mean seriously,
linking to https://man7.org/linux/man-pages/man1/pmdasolaris.1.html and
https://man7.org/linux/man-pages/man1/ibv_srq_pingpong.1.html in the first page
of results does NOT help anyone do anything, ever.)

My contribution to that was https://landley.net/toybox/help.html and an
intention to do videos (which got hung up on prudetube imploding, but I should
get on with it anyway).

In theory "toybox help -au" provides a similar "one line per command" list, but
that has option usage instead of a brief summary of what the command DOES. There
_is_ such a brief summary for most commands at the top of each source file, ala:

$ sed -ns '1p' toys/*/*.c | head -n 10
/* getenforce.c - Get the current SELinux mode
/* load_policy.c - Load an SELinux policy file
/* log.c - Log to logcat.
/* restorecon.c - Restore default security contexts for files
/* runcon.c - Run command in specified security context
/* sendevent.c - Send Linux input events.
/* setenforce.c - Set the current SELinux mode
/* demo_many_options.c - test more than 32 bits worth of option flags
/* demo_number.c - Expose atolx() and human_readable() for testing.
/* demo_scankey.c - collate incoming ansi escape sequences.

But that doesn't become part of the help text (maybe it should?) and doesn't
cover multiple commands in the same source file. And xzcat.c does it wrong.

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

Rob