A mirror of https://github.com/rmyorston/busybox-w32.git https://git.lua4.win/busybox-w32/atom?h=path_search 2024-06-12T11:43:39+00:00 2024-06-12T11:43:39+00:00 Ron Yorston rmy@pobox.com 2024-06-12T11:34:08+00:00 urn:sha1:2817c3d4f3fb60b6719782cde57a6b7347cf2898 In recent versions of Windows the PATH environment variable has a trailing semicolon. This is insignificant to Windows because it's ignored. busybox-w32 conforms to the POSIX interpretation of PATH which treats an empty path element as denoting the current directory. As result, on these versions of Windows executables may by default be run from the current directory, contrary to usual Unix practice. Attempt to detect and remove the trailing semicolon on applet start up. If the user insists, they can add a trailing semicolon to the shell variable PATH and it will be respected in the conventional manner. Adds 88-112 bytes. 2024-05-16T11:48:38+00:00 Ron Yorston rmy@pobox.com 2024-05-16T11:48:38+00:00 urn:sha1:4588cd440e68af132a212d93cd3c4efd73e530b8 busybox-w32 had a dummy implementation of getppid(2) which always returned 1. Provide a more realistic version. The effect is limited: - The PPID shell variable should report a sensible value. - The special value to omit the parent PID 'pidof -o %PPID' should work. Costs 48 bytes. 2024-05-16T11:42:46+00:00 Ron Yorston rmy@pobox.com 2024-05-16T11:42:46+00:00 urn:sha1:2a01fe0325524f7745f60a528d1f3076c098d89d Recent changes to allow orphaned processes to report a parent PID of 1 rely on the assumption that Process32First/Process32Next return parents before children. This isn't guaranteed by the API. Obtain all known PIDs on the first call to procps_scan() so that dead parents can be detected reliably. Costs 48 bytes. 2024-05-14T13:03:25+00:00 Ron Yorston rmy@pobox.com 2024-05-14T13:03:25+00:00 urn:sha1:4e0359ce93c4b0185c5340d03be505b609417b04 If the parent PID doesn't appear in the process table, report it as 1. This more closely matches how orphaned children are handled on UNIX. Adds 96-128 bytes. (GitHub issue #416) 2024-05-14T11:33:03+00:00 Ron Yorston rmy@pobox.com 2024-05-14T11:33:03+00:00 urn:sha1:569de936abb90f4c7cdca9da111a6ea780b135bf A process which has exited may still have its process handle held open by its children. Such a process doesn't appear in the process table. It is thus similar to a zombie process in UNIX. Using kill(1) to interact with such a process was seen to succeed, contrary to expectation. The code for "ordinary" signals in kill(2) did check if the process was still active but didn't treat an attempt to kill an inactive process as an error. Furthermore, sending SIGKILL or the fake signal 0 to a process didn't even check if the process was still active. Rearrange the implementation of kill(2) so that an attempt to signal an inactive process is treated as an error. This also consolidates handling of SIGKILL and signal 0 with "ordinary" signals. Saves 96 bytes. (GitHub issue #416) 2024-04-28T13:19:51+00:00 Ron Yorston rmy@pobox.com 2024-04-28T13:08:12+00:00 urn:sha1:366cf2abfbcf26931052cad297e35f7eee854936 Allow the default history size (used if HISTFILESIZE isn't set) to be configured at build time. This may be less than or equal to the standard history size. (GitHub issue #411) 2024-04-09T07:58:58+00:00 Ron Yorston rmy@pobox.com 2024-04-09T07:58:58+00:00 urn:sha1:fcf3ec2877f042c6957d808e562807089e23ebe6 Implement a 'title' built-in for ash. It's very simple-minded, performs almost no error checking and is completely non-portable. - With no arguments it prints the current console title. - If arguments are provided the *first only* is set as the console title. Costs 88-116 bytes. (GitHub issue #401) 2024-03-29T14:26:13+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2023-07-24T08:01:00+00:00 urn:sha1:c188a345a4d8fe453c4a06796e38d036106fc161 This commit adds a new wcwidth implementation at libbb/wcwidth_alt.c, and uses it instead of the existing implementation when compiling for windows and CONFIG_LAST_SUPPORTED_WCHAR >= 0x30000 - which is the case with the unicode configs/mingw64u_defconfig. The windows-target condition keeps non-windows build unmodified, and the last supported wchar threshold is a semi-hack to allow switching between implementations without adding a new config option (the old code supports codepoints up to 0x2ffff). The new file wcwidth_alt.c was generated by a new scripts/mkwcwidth, which prints a wcwidth implementation using latest unicode data from a local clone of https://github.com/jquast/wcwidth . This repo is the main python wcwidth implementation, and is maintained and up to date. Functional differences from the existing implementation: - Unicode 15.1.0 (latest) with the new version (about 450 ranges of wide and zero-width codepoints), compared to roughly Unicode 5.0 of the existing code (nearly 20 years old spec, about 150 ranges). The new spec includes, among others, various wide icons and emojis, which can now be edited correctly at the shell prompt, have correct alignment in 'ls', etc. - The old implementation returns -1 (non-printable) for surrogates, while the new code returns 1, though this is inconsequential, and POSIX doesn't care. Also libc implementations vary in this regard. Technical differences: - The old version compiles less code/data when the last supported wchar is smaller, while the new version doesn't. This doesn't matter because the new version is enabled only for the full range. - The new version is smaller and relatively straight forward, and fully automated (generated), so updates to newer spec is trivial. The old version mixes data, ad-hoc code (tailored to the data), and preprocessor checks, and is hard to automate updates. The old version has various forms of 32 and 16 bit data ranges, in several arrays, while the new version uses single data array with unified form of 32 bits per range, with two rules: - A data range can't span Unicode planes (enforced, but unlikely required, and if yes, code to split ranges would be simple). - A range can't hold more than 32768 codepoints, so bigger ranges are split automatically (currently there are 2 such ranges). Performance wise, the new version should be faster, even with three times the data ranges. Both versions do effectively at most one binary search in one Unicode plane data, but the new version finds both zero-width and wide-width results in this one search, while the old version only finds zero-width, and to detect wide-width it does an additional linear series of manual range tests, but since most results are width 1, this sequence is performed in most (non-ASCII) calls. In a cursory comparison of the new wcwidth with glibc and musl-libc (both use O(1) lookup tables), with few bodies of text, we're in the same ballpark, with typical speed of 60% or better. Bloat-wise, the new version is about 180 bytes code and 1800 bytes data. If it had similar number of data ranges as the old code (150), the new version would be about 200 bytes smaller, but because the new version has 450 data ranges, it's about 1K bigger. 2024-02-25T08:07:57+00:00 Ron Yorston rmy@pobox.com 2024-02-25T08:07:57+00:00 urn:sha1:12e6f1f719f53e88fa791da5eb610604d989dbee 2024-02-02T11:43:15+00:00 Ron Yorston rmy@pobox.com 2024-02-02T11:43:15+00:00 urn:sha1:8dee37d53a47b8f96ba609d65d85438ef4e14fea - Rename some functions to be more meaningful. - Adjust conditional compilation to clarify which code is required for 'standalone shell' and 'exec prefers applets' settings. This shouldn't result in any change to the behaviour or size of default builds.