Unbreaking allbareconfig (svn 16125).

[Bernhard Fischer]

On Sun, Sep 17, 2006 at 07:04:34PM -0400, Rob Landley wrote:
>On Sunday 17 September 2006 4:50 pm, Bernhard Fischer wrote:
>> On Sun, Sep 17, 2006 at 03:42:27PM -0500, Jason Schoon wrote:
>> >On 9/17/06, Bernhard Fischer <rep.nop at aon.at> wrote:
>> >>
>> >>On Sun, Sep 17, 2006 at 02:05:03PM -0400, Rich Felker wrote:
>> >>>On Sun, Sep 17, 2006 at 05:16:21PM +0200, walter harms wrote:
>> >>>> hi,
>> >>>> just a reminder that paths.h contains:
>> >>>>  _PATH_TTY       "/dev/tty"
>> >>>>  _PATH_CONSOLE   "/dev/console"
>> >>>>
>> >>>> i am just intending to prevent to invent that wheel again.
>> >>>
>> >>>Using #defines for these is even more nonsensical than using external
>> >>>string vars. At least the extern vars save a few bytes. The defines
>> >>>just attempt to abstract something that WILL NEVER CHANGE. Not to
>> >>
>> >>
>> >>>mention these are glibc-specific (all of paths.h is).
>> >>yes.
>> >>There is no reliant content of paths.h at all. We absolutely have to
>> >>provide these as we use them.
>> >
>> >
>> >If we are going to provide them, it would be ideal if we could stick them 
>in
>> >some kind of defined array, or at least provide them as extern const char*.
>> >As noted earlier, just doing the defines does provide simpler changing of
>> >code in one spot, but no space savings.
>> 
>> Most of them should already be extern const char * const
>> See include/libbb.h
>> 
>> I take it that several applets are doing these on their own. These
>> applets want a cleanup to use the libbb provided symbols.
>
>If we mean "/dev", why can't we say "/dev"?  The directory has had a defined 

It's not primarily about "/dev" but about /var/log vs. /var/adm etc.

Furthermore, if someone wants to use "/devices" or "/d" instead of
"/dev" in her router image, then it's only nice if she can change the
path in one place. That's only a minor concern, though.

>meaning for 30 years.  Needing to centralize these in case we want to create 
>non-unix versions of them really isn't something that interests me, and not 
>being able to see what the value actually _is_ when looking only at the code 
>that uses it strikes me as a downside.

{bb_,}path_dev_null should be pretty obvious to parse :)