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
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
