On 19 August 2016 at 10:53, Denys Vlasenko <[email protected]> wrote:
> > I don't understand what you are trying to achieve by this code. > If executable can be found in PATH, what are the benefits from > not running it but running an applet? > > This can be confusing to the user. > If the executable can be found in PATH, we are going to execute it. That's the whole point. If busybox contains f.e. the nandwrite applet, and the symlink from nandwrite to busybox is replaced by the actual nandwrite program, we want to execute the nandwrite program and not the busybox applet. If in another case (without reconfiguring busybox) that link is not overwritten, we want to execute the applet, *while still making use of the NOEXEC trick*. In the current implementation, when you want to make use of the NOEXEC trick for busybox applets, you automatically have to accept that your PATH won't be searched for programs with that applet's name. Writing in the same coding style as the surrounding code would be a start. > You will have to be more specific about which coding style rules I break in my patch, because to me it looks pretty much the same (I use tabs, no camel casing and correct bracket indentation and positioning as far as I know) The other issues should be addressed in the attached patch. I'm open to make any changes that are still needed, just let me know what I need to change.
0001-Add-FEATURE_SH_PATH_BEFORE_NOEXEC.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
