busybox-w32
busybox-w32 copied to clipboard
Behaviour difference for busybox path
C:/TEST $ PATH=""
C:/TEST $ which busybox
C:/TEST/busybox.exe
C:/TEST $ command -v busybox
busybox.exe
C:/TEST $ hash busybox || echo error
C:/TEST $ hash
C:/TEST $
which return full path. command -v return only filename without path. hash apparently do not fail, but it doesn't show anything.
-
which
returning the full path forbusybox
is a special exception:which busybox
is used in the testsuite. -
command
adding the.exe
extension is a bug which I'm looking into fixing now. This only happens if you havebusybox.exe
in your current directory. - In standalone shell mode BusyBox applets behave like shell built-ins so it's expected that
hash
won't report them. (From POSIX: "Utilities provided as built-ins to the shell shall not be reported by hash.")
The latest prerelease should have a fix for the command -v
issue.
I have put the latest binary in 2 copies as busybox.exe and busybox_pre.exe in C:\TEST
I get this:
C:\TEST>busybox_pre.exe ash
C:/TEST $ PATH=".;$PATH"
C:/TEST $ which busybox_pre
./busybox_pre.exe
C:/TEST $ command -v busybox_pre
./busybox_pre.exe
C:/TEST $ hash busybox_pre
C:/TEST $ hash
./busybox_pre.exe
C:/TEST $ hash -r
C:/TEST $ which busybox
C:/TEST/busybox_pre.exe
C:/TEST $ command -v busybox
busybox
C:/TEST $ hash busybox
C:/TEST $ hash
C:/TEST $
Why can't I get the path with command -v busybox
?
Why can't I get the path with command -v busybox?
busybox_pre.exe
includes a busybox
applet which takes precedence over the busybox.exe
binary.
So this is intended, but for me it doesn't make sense, moreover it should at least match filename of the executable. If from busybox_pre.exe I search busybox.exe I cannot find it.
Looks OK to me:
~ $ ./busybox_pre sh
~ $ export PATH=".;$PATH"
~ $ which busybox.exe
./busybox.exe
~ $ command -v busybox.exe
./busybox.exe
~ $
Well, I guess this inconsistency (of virtual busybox applet) lies in upstream busybox.
Reopening because I've made some relevant changes.
-
command -v
now reports the full path when the applet name matches the running binary, similar towhich
. -
which
now only does the special magic for built-in applets when it's run directly from the shell. This makes it possible to revert to the standard behaviour ofwhich
(where it does aPATH
lookup) by running it as, for example,env which busybox
.
The example above, with the two binaries in the current directory, now does this:
C:\Users\rmy>.\busybox_pre sh
~ $ export PATH=".;$PATH"
~ $
~ $ which busybox_pre
./busybox_pre.exe
~ $ command -v busybox_pre
./busybox_pre.exe
~ $
~ $ which busybox
C:/Users/rmy/busybox_pre.exe
~ $ command -v busybox
C:/Users/rmy/busybox_pre.exe
~ $
~ $ env which busybox
./busybox.exe
~ $
Since command
is a shell built-in, not an applet, the env
trick doesn't work for it.
I'm testing it now, it seems really good and really beyond my expectations. Thanks a lot.
Closing this issue as the latest release should have the necessary fixes.