<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2024 at 3:43 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/15/24 16:27, enh wrote:<br>
>     That said, I'm not implementing --longopts without a short opt until somebody<br>
>     comes to me with a use case. And then I would come up with short options. Also,<br>
>     "env" is probably the wrong place to put this unless it's also going to sprout<br>
>     flags to change niceness level and so on: man 7 signal and man 7 environ are<br>
>     different pages.<br>
> <br>
> i know what you mean, but at the same time, the fact that this swiss army knife<br>
> doesn't actually exist is a bug in its own right.<br>
<br>
A swiss army knife tool is not unix. Unix is "do one thing and do it well", and<br>
then combine them either with pipes or via:<br>
<br>
  nice -n 20 env -i potato=wombat nohup nsenter -m chroot thingy /bin/blah<br>
<br>
Having a "sigfilt -INT +HUP cat /proc/potato" in a list like that doesn't seem<br>
like a big lift. (Recycling the "kill" plumbing to understand signal names, and<br>
the -block +unblock stuff from shell options, maybe with the magic name ALL<br>
being every signal. Seems like it might also want a taskset/chmod style<br>
set/unset mask, but I'd want to think about that? Or wait for somebody to<br>
actually need it, since +ALL and -ALL seem like the default use cases...)<br>
<br>
If you were going to extend any of the existing commands above to fiddle with<br>
more signals, "nohup" would be the obvious choice, not "env". (Modulo the silly<br>
stdin/stdout redirection nohup does.)<br>
<br>
> i regularly find people who<br>
> don't realize which of these things there is/isn't a command for. (because not<br>
> only are they separate commands, even the man pages don't generally refer to one<br>
> another. because, like you say, in a sense they _don't_ have anything much to do<br>
> with one another.)<br>
<br>
Back in college they had xerox pages with one line summaries of commands, which<br>
you could "man command" on the machine for.<br></blockquote><div><br></div><div>i remember when apropros(1) was useful...</div><div><br></div><div>~$ apropos nice<br>nice: nothing appropriate.<br>~$ <br></div><div> </div><div>:-(</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For a while <a href="https://man7.org/linux/man-pages/dir_section_1.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/dir_section_1.html</a> and friends were<br>
useful but then he dumped 8 zillion unrelated packages into them, reproducing<br>
Yogi Bera's "nobody goes there anymore, it's too crowded". (I mean seriously,<br>
linking to <a href="https://man7.org/linux/man-pages/man1/pmdasolaris.1.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man1/pmdasolaris.1.html</a> and<br>
<a href="https://man7.org/linux/man-pages/man1/ibv_srq_pingpong.1.html" rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man1/ibv_srq_pingpong.1.html</a> in the first page<br>
of results does NOT help anyone do anything, ever.)<br>
<br>
My contribution to that was <a href="https://landley.net/toybox/help.html" rel="noreferrer" target="_blank">https://landley.net/toybox/help.html</a> and an<br>
intention to do videos (which got hung up on prudetube imploding, but I should<br>
get on with it anyway).<br>
<br>
In theory "toybox help -au" provides a similar "one line per command" list, but<br>
that has option usage instead of a brief summary of what the command DOES. There<br>
_is_ such a brief summary for most commands at the top of each source file, ala:<br>
<br>
$ sed -ns '1p' toys/*/*.c | head -n 10<br>
/* getenforce.c - Get the current SELinux mode<br>
/* load_policy.c - Load an SELinux policy file<br>
/* log.c - Log to logcat.<br>
/* restorecon.c - Restore default security contexts for files<br>
/* runcon.c - Run command in specified security context<br>
/* sendevent.c - Send Linux input events.<br>
/* setenforce.c - Set the current SELinux mode<br>
/* demo_many_options.c - test more than 32 bits worth of option flags<br>
/* demo_number.c - Expose atolx() and human_readable() for testing.<br>
/* demo_scankey.c - collate incoming ansi escape sequences.<br>
<br>
But that doesn't become part of the help text (maybe it should?) and doesn't<br>
cover multiple commands in the same source file. And xzcat.c does it wrong.<br>
<br>
Anyway: if a "toybox cheat sheet" seems like a good thing, we're like 80% of the<br>
way there already?<br></blockquote><div><br></div><div>maybe a toybox apropros(1)?</div><div><br></div><div>(although my `apropos nice` example is a bad one because renice(1) has no description.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>