On Thu, Jun 26, 2025 at 08:55:54AM +0200, Csókás Bence wrote: > Hi, > > On 2025. 06. 26. 0:00, Nadav Tasher wrote: > > On Wed, Jun 25, 2025 at 11:54:56AM +0200, Csókás Bence wrote: > > > Hi, > > > > > > On 2025. 06. 25. 6:11, Nadav Tasher wrote: > > > > On Tue, Jun 24, 2025 at 02:35:58PM +0200, Csókás Bence wrote: > > > > > Hi, > > > > > > > > > > On 2025. 06. 14. 18:10, Nadav Tasher wrote: > > > > > > To improve applet execution coverage, get_shell_name() will return > > > > > > "sh" > > > > > > when applets are prefered and "sh" is defined as a shell applet. > > > > > > > > > > > > This allows for more applets to execute sub-applets when spawning > > > > > > shells. > > > > > > > > > > > > Signed-off-by: Nadav Tasher <[email protected]> > > > > > > > > > > Maybe it's just me, but why are we overriding all users' shell > > > > > preferences > > > > > depending on a Kconfig option? Isn't there a better way? > > > > > > > > > > Bence > > > > > > > > > This is intentional, since it is the only way we can guarantee applets > > > > which call system() or execv(get_shell_name(), ...) execute a > > > > self-contained > > > > shell that honors the "prefer applets" Kconfig. > > > > > > Okay, I understand it for system(), but for the execv() one, the only > > > reason > > > for a developer to write that one is when they _explicitly_ want to honor > > > the user's shell preference. Which now we disregard completely. > > > > > Actually, I'm not sure about that. > > In the entire BusyBox codebase, the only times a shell is executed using > > get_shell_name(), is when system() is insufficient (like when you need to > > capture > > the output or pipe the shell to another process). > > > > We need to force this behaviour to guarentee that only applets will be > > > > executed, since get_shell_name() will result in ash or hush being used > > > > instead of /bin/sh or others. > > Ah, I see. But in that case, why do they even call out to get_shell_name(), > wouldn't exec("sh", ...) be better? > > Bence > It makes sense to use get_shell_name(), since in some cases /bin/sh might not exist, as some systems don't even have it as a symlink to anything else (BusyBox runs on non-POSIX).
Moreover, there might not be a BusyBox shell in said BusyBox, and even if there is, there is no guarentee that a symlink to it is installed in a PATH directory. In the scope of my proposed change, this change makes sense (and it only affects builds with FEATURE_PREFER_APPLETS). Nadav _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
