which,ash: changes to which/command/type

Change how 'which' detects if it was run from a standalone shell:
the shell passes the undocumented '-s' option.  This is stricter
and more reliable than the previous method of checking the name
of the binary.

Add a function to determine the binary associated with a given
applet name.  This makes it possible for 'which' and 'command -v'
to list the correct binary even for applets other than 'busybox'.
For example, when the binary is called 'sh.exe' 'which sh' will
report its path.

In standalone shell mode 'command -V' and 'type' now report "xxx
is a builtin applet" rather than "xxx is xxx", which is true but
not very illuminating.

(GitHub issue #248)

1 files changed, 21 insertions, 0 deletions

diff --git a/win32/mingw.c b/win32/mingw.c
index 063a0c546..0fa2a1b8f 100644
--- a/win32/mingw.c
+++ b/win32/mingw.c
@@ -2130,3 +2130,24 @@ int is_relative_path(const char *path)
 {
         return !is_dir_sep(path[0]) && !has_dos_drive_prefix(path);
 }
+
+#if ENABLE_FEATURE_SH_STANDALONE
+/*
+ * In standalone shell mode it's possible there's no binary file
+ * corresponding to an applet name.  There's one case where it's
+ * easy to determine the corresponding binary:  if the applet name
+ * matches the file name from bb_busybox_exec_path (with appropriate
+ * allowance for 'busybox*.exe').
+ */
+const char *applet_to_exe(const char *name)
+{
+        const char *exefile = bb_basename(bb_busybox_exec_path);
+        const char *exesuff = is_prefixed_with_case(exefile, name);
+
+        if (exesuff && (strcmp(name, "busybox") == 0 ||
+                                                strcasecmp(exesuff, ".exe") == 0)) {
+                return bb_busybox_exec_path;
+        }
+        return name;
+}
+#endif