On 10/05/2018 05:25 PM, enh wrote: > On Fri, Oct 5, 2018 at 2:45 PM Rob Landley <[email protected]> wrote: >> >> On 10/05/2018 02:41 PM, enh wrote: >>> On Fri, Oct 5, 2018 at 11:18 AM Rob Landley <[email protected]> wrote: >>>> >>>> On 10/02/2018 06:21 PM, enh wrote: >>>>> (in case it's not obvious, this is on top of my other getconf patch >>>>> from earlier today.) >>>> >>>> Applied, but: >>> >>> forgot to push? >> >> Yup. >> >>>> 1) getconf -l only outputting symbol names was intentional, it's that whole >>>> "unix way" Mike Gancarz wrote a loely book about. Output that's easily tool >>>> processable, so you can do "for i in $(getconf)" for example. (Toybox >>>> produces >>>> just the command names for the same reason.) I understand your motivation >>>> for >>>> changing that, but it makes me wince. >>> >>> my motivation was "how else do we explain which ones are pathconf?", >>> which you need to know because all the others require 0 args, but >>> pathconf requires 1 arg. >> >> The default is "/" if you just go "getconf -a". > > weird. that seems far less useful than '.'.
I think it's trying to give you VFS statistics? (Wild guess. No guarantee / isn't crazy either, of course.) > (i'm not really sure how `getconf -a` is even useful. looks like it's > meant for interactive use when you don't know what a thing's called. > so you do `getconf -a | grep -i uucp` or whatever.) Snapshotting a system's stats and comparing with another system, I think. (My own test case above was diff -u of two outputs.) >>> but i can do that while you do something more useful :-) i'll fix the >>> "undefined" behavior too, since i found one caller that was expecting >>> it... (but i'll wait for you to push first, in case you'd made >>> additional changes.) >> >> I didn't. I dunno what success look like here either. (And too busy at work >> to >> think much about it until now.) > > the BSD getconf seems less stupid: `getconf -a` shows you the non-path > stuff, `getconf -a PATH` shows you just the path stuff. sounds > reasonable? *shrug* I'm happy to be led here. My motivation for adding this was builds (mainly the kernel build but there were others) complaining about a lack of getconf. Beyond that I haven't got a test case, I just objected to the first contribution I got here having no way to list the keys it supported... Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
