On Sat, Oct 6, 2018 at 10:20 AM Rob Landley <r...@landley.net> wrote: > > On 10/05/2018 05:25 PM, enh wrote: > > On Fri, Oct 5, 2018 at 2:45 PM Rob Landley <r...@landley.net> wrote: > >> > >> On 10/05/2018 02:41 PM, enh wrote: > >>> On Fri, Oct 5, 2018 at 11:18 AM Rob Landley <r...@landley.net> 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.
since i don't really care either, i've sent you patch that copies the FSF behavior of assuming "/" if no path is supplied. i personally think the BSD behavior is more sensible, but since we _are_ aiming to replace various Linux tools not _aren't_ targeting BSD, i'm assuming that the FSF behavior is more likely to be useful to our target audience. > 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 Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
