On Fri, Mar 15, 2024 at 3:43 PM Rob Landley <r...@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. ~$ :-( 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? > maybe a toybox apropros(1)? (although my `apropos nice` example is a bad one because renice(1) has no description.) > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net