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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
