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-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-27T16:47:50+00:00 Ron Yorston rmy@pobox.com 2024-04-27T16:47:50+00:00 urn:sha1:b5e4d3569f8ee48164b9845801bbc4eb8f62171d Keep the maximum history size at 1023 but make the default 383. This gives a modest increase over the previous default of 255 while allowing users to increase or decrease the history size using the HISTFILESIZE environment variable. (GitHub issue #411) 2024-04-02T18:02:26+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2024-04-02T08:56:10+00:00 urn:sha1:d83942876e089a63526b9624c74407cdefd6b4ac interval, in_interval_table, and in_uint16_table were previously not compiled when using the new wcwidth (commit c188a345a) because they're used by the old wcwidth but not by the new one. But they're also used by the BIDI routines. mingw64u_defconfig doesn't enable bidi (rightly - it's not working well), but it'd still be nice to allow enabling bidi while the new wcwidth is in effect. Enable the tables lookup code if BIDI is enabled. 2024-03-29T14:32:57+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2024-03-29T14:32:57+00:00 urn:sha1:95e0a07f891947c5c2d66cd837a5aa379b962308 This reverts commit 878b3cd27fe83f2b0ff476b884c34d165be0072c. It's no longer required, since the last commit uses a new wcwidth implementation which covers the cases added by commit 878b3cd2 . 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-16T12:06:15+00:00 Ron Yorston rmy@pobox.com 2024-02-16T12:06:15+00:00 urn:sha1:0200baa675d3b51c0f021da7728353ee7ceedba4 The last two commits allow EXTRAVERSION to track the current state of a git repository. The build system was unable to determine which files were affected by changes to EXTRAVERSION and caused a full rebuild when it changed. Alter how the version information is passed to the code so only a handful of files need to be rebuilt when it changes. 2024-02-02T14:18:28+00:00 Ron Yorston rmy@pobox.com 2024-02-02T14:15:09+00:00 urn:sha1:5a6d050af3aca3c8710e781e7082adec801201c8 In the Microsoft Windows build stat(1) requires find_mount_point() from libbb. This won't be available unless df(1) is also enabled. Add a dependency so stat(1) can be built without df(1). This may result in find_mount_point() being compiled needlessly in some upstream builds, but we can live with that. (GitHub issue #385) 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. 2024-01-24T11:56:07+00:00 Ron Yorston rmy@pobox.com 2024-01-24T11:56:07+00:00 urn:sha1:e90fe5ece9e76837fb438e90da77b29eff4e7456 In external_exists() in appletlib.c it's necessary to take a copy of the pointer to the allocated variable path1 so it can be freed: find_executable() will change its value.