Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Busybox automatically uses builtin commands, ignoring ones in $PATH #151

Open
Semphriss opened this issue Jul 27, 2024 · 3 comments
Open

Comments

@Semphriss
Copy link
Contributor

I've compiled GNU grep and sed and replaced the Busybox ones in my path, but calling them from the shell will always call the Busybox version unless I specify an absolute path.

Would it be possible to make Busybox give priority to executables in the path rather than its own builtins?

@rmyorston
Copy link

rmyorston commented Jul 27, 2024

The shell in a default build of BusyBox for Windows always looks for a built-in applet before searching PATH. This preference for applets can be overridden by setting the shell variable BB_OVERRIDE_APPLETS (as described in the release notes for FRP-5181).

In the particular case above, setting BB_OVERRIDE_APPLETS="grep sed" will unconditionally override the two applets and always search for a suitable alternative on PATH.

Alternatively, the setting BB_OVERRIDE_APPLETS=";grep sed" will first look on PATH but if no matching executable is found it'll fall back to using the built-in applet.

It's also possible to configure this sort of setting at compile time, as mentioned in the FRP-5301 release notes.

For example, setting the build-time configuration OVERRIDE_APPLETS to the string + will result in a BusyBox shell which (by default) always searches PATH first and only uses a built-in applet if that search fails.

@Semphriss
Copy link
Contributor Author

Thanks for the info!

Small typo, you wrote "BB_OVERRIDE_APPLET" (singular) in your usage examples. I'm specifying just in case somebody else comes across this issue and tries to copy-paste the examples.

@rmyorston
Copy link

Yes, I noticed the error myself and updated the comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants