On 3/15/24 17:48, enh wrote: > > > On Fri, Mar 15, 2024 at 3:43 PM Rob Landley <r...@landley.net > <mailto: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. > ~$ > > :-(
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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net