On Fri, 27 Jun 2025 at 00:35, Harald van Dijk <har...@gigawatt.nl> wrote: > > On 26/06/2025 23:18, Nadav Tasher wrote: > > On Thu, Jun 26, 2025 at 10:38:14PM +0100, Harald van Dijk wrote: > >> 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. > > That doesn't sound quite right. Any applet that uses system() or > get_shell_name() should run a busybox-internal shell when the user > account is not specifically configured to use a different shell, agreed > so far.
There is no "user account" and there is nothing apart from a busybox static binary, in principle. This is the **main** concept of a standalone busybox, being the WHOLE system apart from the kernel which in a broader view, does not necessarily be a Linux kernel. I agree that usually a initrd image provides a single file (loop or loopz) which contains also a root filesystem in which busybox isn't the WHOLE system but just a static binary, by extending this the ONLY binary. The concept of "standalone busybox" goes a little further. However for the moment, it would be fine to see the "standalone" mode in this way: the only executable in the system which has no shared libraries, also. Under this PoV and "extreme" conditions, it is acceptable that busybox "standalone" acts differently. =-> https://g.co/gemini/share/18c28016d388 Before proceeding or getting involved in this conversation, I suggest to check-out this conversation of mine with Gemini. Because wherever a chatbot can reach, it establishes the lowest bar from which humans should start before engaging another human without potentially wasting his/her time. Hard to accept, but fair. I hope this helps, R- _______________________________________________ busybox mailing list busybox@busybox.net https://lists.busybox.net/mailman/listinfo/busybox
