busybox-w32/debianutils/which.c, branch long_paths

Further tweaks to make_single_applets.sh

2025-10-29T06:19:46+00:00

Changes to the applet configurations of 'reset' and 'which' in the Microsoft Windows port resulted in these applets being enabled in every single-applet executable built by make_single_applets.sh. Alter the configuration to avoid this. Remove PLATFORM_POSIX and PLATFORM_MINGW32 from the list of applets to be built. (GitHub issue #536)

Merge branch 'busybox' into merge

2024-10-08T11:09:30+00:00

libbb: modify find_executable() to not temporarily write to PATH

2024-10-08T02:03:17+00:00

This allows to simplify "which" applet code function old new delta find_executable 93 111 +18 which_main 191 177 -14 builtin_source 316 294 -22 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/2 up/down: 18/-36) Total: -18 bytes Signed-off-by: Denys Vlasenko

which,ash: code shrink detection of standalone shell

2024-08-17T10:57:45+00:00

Commit 6d87be4d7 (which,ash: changes to which/command/type) let 'which' detect when it's run from a standalone shell by having the shell pass the undocumented '-s' option. A better solution is to alter argv[0] when 'which' is run from a standalone shell. This is possible because the code path through run_noexec_applet_and_exit() and which_main() doesn't actually use argv[0]. - No special treatment is required in ash when 'which' has no arguments or the '--help' option. - tryexec() no longer needs an extra element before the start of argv. The commit 027fb22e2 can be reverted and the allocation of argv in evalcommand() simplified. - 'which' no longer needs to handle the '-s' option. Saves 96-104 bytes.

Merge branch 'busybox' into merge

2023-07-13T07:06:26+00:00

Update applet size estimates

2023-07-10T15:25:21+00:00

Signed-off-by: Denys Vlasenko

win32: code shrink detection of executables

2023-03-16T10:47:09+00:00

Add a function, file_is_win32_exe(), to detect if a path refers to an executable. It tries adding extensions if necessary. Use this in a number of places to replace common code of the form path = alloc_ext_space(cmd); if (add_win32_extension(path) || file_is_executable(path)) Saves 32-48 bytes.

win32: revert special treatment of Unix-style absolute paths

2022-10-26T10:47:42+00:00

Commit 605972390 (win32: handle Unix-style absolute paths for executables) added special treatment of paths for executables starting with a slash. Such paths are absolute on Unix but are relative to the current drive on Windows. On reflection this commit did more than necessary. Later commits provided special treatment only for paths starting with locations traditionally used to contain binaries on Unix. This is probably sufficient. Problems introduced by commit 605972390 include: - If the current drive isn't the system drive tab completion of a command starting with a slash confusingly references the system drive. - Building busybox-w32 with w64devkit fails on drives other than the system drive. Revert the changes introduced by commit 605972390. This saves 192 bytes. (GitHub issue #239)

win32: search PATH for missing Unix-style executables

2022-05-06T08:30:43+00:00

Commit 41ef232fc5 (win32: use built-in applets for non-existent binaries with Unix-style paths) alters what happens when trying to find an executable. If all of the following apply: - the pathname starts with one of the standard directories for Unix executables (/bin, /usr/bin, /sbin, /usr/sbin); - the file isn't found relative to the system root; - the basename matches an applet then the applet is run. Further extend the procedure so that if the first two conditions are met and either: - the PREFER_APPLETS and SH_STANDALONE features are enabled and the basename *doesn't* match an applet or - the PREFER_APPLETS and SH_STANDALONE features are disabled then PATH is searched for the basename. This affects: - how interpreters and binaries are spawned by mingw_spawn_interpreter() and mingw_spawnvp(); - how 'which' and the shell search for binaries. Special steps need to be taken in the shell to avoid treating shell built-ins and functions as applets. As a consequence of this change: - An executable that isn't an applet, say curl.exe, can be run as /usr/bin/curl so long as it's in a directory in PATH. It doesn't have to be in C:/usr/bin. - If the PREFER_APPLETS and SH_STANDALONE features are disabled binaries can be run using paths referring to standard Unix directories even if they're installed elsewhere in PATH.

which,ash: changes to which/command/type

2022-05-01T10:03:10+00:00

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)