On Wednesday 17 June 2009 12:16:08 Denys Vlasenko wrote:
> On Tue, Jun 16, 2009 at 8:26 PM, Rob Landley<[email protected]> wrote:
> > On Monday 08 June 2009 05:15:26 Denys Vlasenko wrote:
> >> On Mon, Jun 8, 2009 at 4:02 AM, Barney Barumba<[email protected]> 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.
Sounds good to me.
> > which doesn't seem like something
> > you'd want to do to a search path.
>
> Thus, messages.c is more like strings.c.
I still find its existence a bit confusing. The first string in there,
bb_msg_memory_exhausted, exists so things like ash can reimplement xmalloc()
and xrealloc() and xstrdup() and friends. I'm really not sure why they do
that, considering that even on a 32 bit system allocation calls will only ever
return 0 if you've exhausted _virtual_ address space, and a lack of _physical_
memory will get detected later at page fault time by the OOM killer, so it's
not a very useful indicator of anything. (Unless ash is going to start
supporting nommu systems soon? Even so, why does it have a different mechanism
than the rest of busybox? Historical reasons?)
Common messages like that make me think "common code is being reimplemented in
multiple places". Otherwise why would multiple places need to use the same
messages?
> > 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:
Always a good reason. :)
> bb_PATH_root_path + sizeof("PATH=/sbin:/usr/sbin") is a non-root PATH.
It might be nice to add a comment in the source code acknowledging that
_PATH_STDPATH exists and we've chosen not to use it because XXX.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
