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

Rob Landley rob at landley.net
Fri Oct 5 14:45:00 PDT 2018


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".

Hmmm, but it insists when you specify an argument:

$ getconf FILESIZEBITS
Usage: getconf [-v specification] variable_name [pathname]
       getconf -a [pathname]
$ getconf FILESIZEBITS /
64

That's really stupid. (The ubuntu one, I mean.)

> it didn't seem reasonable to do that in
> --help, and although i considered something like adding '*' to the
> pathconf ones, that breaks the traditional unix style that you were
> going for but without actually fixing my problem...

Indeed.

>> 2) I missed that upstream has the "-a" option which lists everything, which is
>> why they don't have a -l. (I don't think ubuntu 14.04 had this, but my test
>> system died.) We should probably implement that, I might take a stab this weekend.
> 
> not _everything_ --- just the ones that are defined (and i'm guessing
> it uses '.' for the pathconf ones?).

Pretty sure it uses /

$ diff -u <(cd /; getconf -a) <(cd /proc; getconf -a)
$ diff -u <(getconf -a /) <(getconf -a /proc) | wc
     19      45     742

> 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.)

>> Rob

Rob



More information about the Toybox mailing list