[Toybox] [PATCH] getconf: add pathconf(3) variables.

[enh]

On Sat, Oct 6, 2018 at 10:20 AM Rob Landley <rob at landley.net> wrote:
>
> On 10/05/2018 05:25 PM, enh wrote:
> > On Fri, Oct 5, 2018 at 2:45 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 10/05/2018 02:41 PM, enh wrote:
> >>> On Fri, Oct 5, 2018 at 11:18 AM Rob Landley <rob at 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