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

[Rob Landley]

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.

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