ifup run-parts not found

Denys Vlasenko vda.linux at googlemail.com
Wed Jun 17 17:16:08 UTC 2009


On Tue, Jun 16, 2009 at 8:26 PM, Rob Landley<rob at landley.net> wrote:
> On Monday 08 June 2009 05:15:26 Denys Vlasenko wrote:
>> On Mon, Jun 8, 2009 at 4:02 AM, Barney Barumba<barney.b at iname.com> wrote:
>> > On Fri, 5 Jun 2009, Denys Vlasenko wrote:
>> >> Pretty sure I met this problem ages ago.
>> >>
>> >> The PATH is not exported.  God alone knows why not, but it isn't.
>> >>
>> >> Add the line
>> >>
>> >>       export PATH
>> >>
>> >> to /etc/profile and you might be in luck.
>> >
>> > Still not sure what was causing it, but the problem only occurred when
>> > I executed a shell directly from the /init script. When I link /init to
>> > /bin/busybox and launch a shell from /etc/inittab everything works fine.
>> >
>> > I was only using the /init shell for testing while building the system,
>> > so for me this is not really a problem any more. I'll try exporting the
>> > path though just to see if that works, and let you know.
>>
>> My theory is with PATH unset, a default PATH is used by libc,
>> and was finding run-parts.
>
> Close.  If PATH is unset, a default PATH is supplied by your command shell.
> (And lots of things exec stuff through system() which bounces off a shell.)
>
> In busybox's case (for ash, anyway), it's a hidden and torturous code path
> that eventually winds up in libbb/messages.c with:
>
> const char bb_PATH_root_path[] ALIGN1 =
>        "PATH=/sbin:/usr/sbin:/bin:/usr/bin" BB_ADDITIONAL_PATH;
>
> I thought the original reason for "messages.c" was to contralize strings that
> might be translated into foreign languages,

I do not want to translate anything. Its a huge PITA with no real
gain. Command line users already know English well enough
to understand the simple subset of it used in messages.

> which doesn't seem like something
> you'd want to do to a search path.

Thus, messages.c is more like strings.c.

> Expecially not one that has a standard
> definition we're not using: I have no idea why we're not just #including
> /usr/include/paths.h out of the standard headers and using _PATH_STDPATH, but
> oh well.

Because I want to cheat:

bb_PATH_root_path + sizeof("PATH=/sbin:/usr/sbin") is a non-root PATH.

--
vda


More information about the busybox mailing list