On Thu, Jun 26, 2025 at 10:38:14PM +0100, Harald van Dijk wrote:
> On 26/06/2025 22:06, Nadav Tasher wrote:
> > On Thu, Jun 26, 2025 at 12:01:42PM +0100, Harald van Dijk wrote:
> > > I get what you're going for but I think this is the wrong way of doing it.
> > > get_shell_name() uses, in order of preference, the SHELL environment
> > > variable, the shell specified in /etc/passwd, DEFAULT_SHELL. With your new
> > > config option, DEFAULT_SHELL could be "sh" (or maybe "-sh" to continue to
> > > act as a login shell), but it does not look right that the other two would
> > > be ignored. If the user requests a different shell, let the user get that
> > > different shell.
> >
> > IMO, the odds of get_shell_name() returning a non-sh-like shell are slim.
> > I think that if someone uses BusyBox with this feature, it's already very
> > clear to them that there were multiple monkey-patches involved to get it
> > working.
>
> I would not be too sure about that. It's entirely reasonable that a device
> that use busybox to also allow user accounts to be created (I have such
> devices myself), and for those user accounts to specify a different shell
> like csh or fish. Even if limiting it to sh-compatible shells, it's kind of
> important that when the user installs bash and specifies that they want
> their shell to be bash, that they get bash.
>
Yes these are valid scenareos - but in these scenareos you'd probably have the
FEATURE_PREFER_APPLETS config disabled anyway (disabled by default).
> > I think this should be left as-is, but I understand your concern about this
> > being non-POSIX / off-standard in a way.
> >
> > I could make this behaviour configurable using a new Kconfig option.
> > I'll make it very clear that this is experimental, and that it probably
> > breaks some conventions.
> >
> > WDYT?
>
> I don't really see why you would want this even as a Kconfig option,
> personally, but perhaps I do not understand your use case well enough. I get
> why you want to have the default behaviour to be to execute things
> internally, and I support that. I don't get why you want to also execute
> things internally when the user requests not to execute things internally.
> Could you explain why you want that?
>
Yes, I'll elaborate.
This patchset aims to provide a way to compile BusyBox so that it generates a
completely stand-alone binary (and by that I do not necessarily mean a static
binary), that acts as a full (or partial, user decides) *NIX system.
This means that applets will try to execute other applets, before falling back
to binary executions (a Kconfig to forbid external executions also exists).
Since that is the desired behaviour, any applet that uses the system() function
or exec*() with get_shell_name(), needs to run a BusyBox-internal shell, so that
this shell will keep on calling internal applets (by function) instead of
executing external binaries.
This way, the crond applet that you mentioned would use "sh" (which leads to
ash or hush), then that internal shell with execute the desired job command,
resulting in applet execution (find -> tar + gzip for example).
Most of these "executions" will end up being just fork() -> {APPLET}_main(),
instead of fork() -> execvp().
> Cheers,
> Harald van Dijk
Nadav
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
