| Commit message (Collapse) | Author | Files | Lines |
|
Updated using:
./scripts/mkwcwidth DL=16.0.0 FAST_FUNC > libbb/wcwidth_alt.c
The latest currently is 17.0.0, but because we were previously with
15.1 tables, have the 16.0 tables in history just in case.
Next commit will update to the latest version.
|
|
Previously, scripts/mkwcwidth generated a wcwidth implementation based
on input from the python wcwidth: https://github.com/jquast/wcwidth .
However, that project is not updated frequently, and the less
dependencies - the better.
This new script instead prints an implementation based directly on the
original Unicode files - which it can also download.
It generates the same code as before (same data structures, etc).
It was then used to re-generate libbb/wcwidth_alt.c, as follows:
./scripts/mkwcwidth DL=15.1.0 FAST_FUNC > libbb/wcwidth_alt.c
This is the same Unicode version as the previous file, just to make
the codepoint differences visible easily.
These differences are very small, and the script itself explains where
and why it differs from https://github.com/jquast/wcwidth .
Next commits will update the tables to the latest unicode version.
|
|
The next commit will replace scripts/mkwcwidth, and the new script
doesn't add codepoint comments, so delete the comments now, so that
it would be easier to compare wcwidth_alt.c when it's updated using
the new script.
|
|
When unicode is enabled at build time, but disabled at runtime
(commit 208649d7), we already do some runtime ACP tests and act
accordingly (we know unicode is not in effect) in mingw non-upstream
code (UTF8_OUTPUT, etc - see previous commit).
However, there's at least one upstream unicode code path which was
not touched until now - printable chars.
This code is used by applets like "ls" to display "?" instead of
non-printable chars, where upstream considers byte values above 127
as non-printable, but the busybox-w32 code should consider them
printable when unicode is disabled (ANSI codepage).
We already have code for that when unicode is disabled at build time
(at printable_string2), but when unicode is enabled at build time then
it enters a different code path (which still tests dynamically whether
unicode is enabled - and correctly deduces that it isn't when unicode
is disabled despite the utf8 manifest).
Modify unicode_conv_to_printable2 similar to how printable_string2 is
modified - but only when unicode is disabled due to the manifest not
being in effect (unicode build on win XP/7/8).
A unicode build on XP/7/8 _should_ now behave reasonably close to
a non-unicode build on such systems.
Known issues:
There's one known issue, and that's tab completion doesn't case-fix
the completion. E.g. ~/desk<tab> completes to ~/desktop/ instead of
to ~/Desktop/ (capital D).
This issue exists in unicode builds also on win10+, and is caused by
the fact that when unicode is enabled at build-time, line-editing
uses (32bit) wchar_t, and of the mingw changes in line-edit, only
the backslash-to-slash was ported also to the wchar_t editing, while
case-fix was not (see FIXME at libbb/lineedit.c in commit 0efc7474).
status:
This combination of unicode-enabled build running on XP/7/8 was NOT
tested extensively, so some issues might remain, but other than the
case-fix with tab-completion, there are no known issues.
Main area where more testing is needed is editing (probably mainly
interactive shell command prompt and vi).
Testing:
To test how a unicode-enabled build behaves when unicode is disabled
in runtime, other than actually running it on win XP/7/8, one way
would be to find a combination of build-config values to enable all
the unicode features but not the manifest itself, but that's tricky.
Instead, one could simply delete the manifest from a pre-compiled
binary (mingw{64u,32w}_defconfig), so that it would run in ANSI mode
even on win10+, with the build-time unicode code paths still enabled
at the binary.
One tool to edit windows binaries is https://github.com/avih/perc .
To delete the manifest, use "perc -D -t MANIFEST busybox.exe" .
|
|
Before commit 208649d7, when unicode was enabled (utf8 manifest), the
build refused to run unless the manifest was in effect (the codepage
is UTF8, and argv, win APIs, and internal strings are UTF8 too).
That commit, however, allows such build to also run where the manifest
has no effect (prior to win10 1903), and so some of the unicode code
paths behave incorrectly in such cases when the runtime ACP is ANSI.
This commit fixes the UTF8_OUTPUT code path in such case, to also
check ACP, instead of unconditionally printing to the console as UTF8.
When ACP is not UTF8, it now behaves identically to a non-unicode
build (doing output conversion from ACP to console out-CP if needed).
Example: create a filename which is valid in the ANSI codepage with
chars above 127, and do "echo *" (glob expansion), which now prints the
name correctly, but previously it didn't when the build has unicode
enabled at buildtime but not runtime (see next why not just try "ls").
This covers the existing busybox-w32 unicode code paths, as the others
(UTF8_INPUT and unicode-aware editing) already had runtime ACP test,
so unicode _should_ be disabled correctly if the runtime ACP is ANSI.
However, there are also some new upstream unicode code paths which
can be entered now - when unicode is enabled at build time but
disabled at runtime.
One we know of is printable-chars code, which is used by applets like
"ls", and so currently, when unicode is enabled at build time but
disabled at runtime, "ls" displays valid ANSI chars above 127 as "?".
The next commit will address this.
|
|
Return "armv7" in this case.
|
|
The fact that "environ" is not assignable goes the same for
both 32 and 64 bit ARM on msvcrt - this is not an issue on UCRT
as noted in c44f23f4acbbd854eccd962110e41343d8f03296.
This extends the original workaround from
ea8742bc1657cd0aae32ac555560c8228795488f to 32 bit ARM too.
|
|
Now that a binary with a UTF-8 manifest can run on Windows XP
it's possible to configure a build which supports Unicode on
Windows 10+ but which still runs on legacy systems.
- Add the config file mingw32w_defconfig. This is a 32-bit build
with the UTF-8 manifest which also runs on legacy systems.
- A new config option, FEATURE_FAIL_IF_UTF8_MANIFEST_UNSUPPORTED,
allows the check for legacy systems to be skipped.
- An incompatibility with Windows XP in writeCon_utf8() has been
fixed.
See this GitHub issue for details:
https://github.com/skeeto/w64devkit/issues/315
|
|
It seems that the UTF-8 manifest can be adjusted to avoid binaries
failing to run on Windows XP.
Make the necessary adjustment. This doesn't affect the legacy
builds, only those with Unicode enabled. Nor does it change the
code which prevents Unicode builds from running on platforms
that don't support the manifest.
See this GitHub issue for details:
https://github.com/skeeto/w64devkit/issues/315
|
|
Immediate-mode macros shouldn't be recursively expanded, but are
subject to suffix and pattern substitution.
Adds 16 bytes to the 32-bit build.
(pdpmake GitHub issue 77)
|
|
The implementation of localtime(3) in the Microsoft Windows
runtime only accepts arguments between the Unix epoch (1970)
and either 2038 or 3000 for 32-bit or 64-bit systems respectively.
For values outside those limits it returns a NULL pointer.
Unfortunately, upstream BusyBox hardly ever bothers to check the
return value. Thus, when a call to stat(2) returned an all-zero
FILETIME for a file, the 'stat' applet failed. An all-zero FILETIME
represents a date in 1600, which is clearly before the Unix epoch.
Add a wrapper to localtime(3) which detects an out-of-range value
and returns a valid 'struct tm' for the Unix epoch. This is easier
than adding checks on the return value of every call to localtime(3).
Adds 32-48 bytes.
(GitHub issue #548)
|
|
The command 'read -t 10' couldn't be interrupted by ctrl-c
when ash was running in the mintty terminal emulator.
This issue was introduced by commits 8e6991733 and b2901ce8e
which fixed other problems with the 'read' builtin.
Rearrange the code to avoid calling poll(2) in an interactive
shell on Windows.
(GitHub issue #547)
|
|
It was found that 'mkdir -p --verbose C:/' incorrectly reported
that 'C:/' was created.
Commit 0e0b5e9ff8 (mingw.c: ignore EACCES from mkdir if directory
exists) fixed a failure to create directories but caused the
`mkdir` applet to issue the wrong diagnostic.
The underlying problem is in the Windows runtime implementation
of _mkdir(): it can return the wrong errno in some cases, EACCES
instead of EEXIST.
Having the mkdir(2) wrapper return the correct errno should fix
both the directory creation and verbose diagnostic problems.
The website referenced in the previous commit is no longer
available. archive.org has a copy:
https://web.archive.org/web/20150224075238/http://www.apijunkie.com/APIJunkie/blog/post/2009/12/22/_mkdir-C-runtime-library-function-might-return-unexpected-error-values.aspx
(GitHub issue #546)
|
|
If the files being pasted had different numbers of lines the
output was incorrect.
Rewrite the loop over all lines to allow for this. Add tests for
such conditions.
Adds 64-80 bytes.
(GitHub issue #542)
|
|
Treat /dev/tty as an alias for Windows' 'con' device. The code
is similar to that used for /dev/null.
Adds 24-48 bytes.
(GitHub issue #538)
|
|
Fixes missing [-s] option in trivial usage section of `eject --help`
function old new delta
packed_usage 35125 35127 +2
Signed-off-by: Nir Lichtman <nir@lichtman.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
xatoull_range_sfx - 49 +49
dd_main 1607 1640 +33
bb_banner 47 46 -1
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/1 up/down: 82/-1) Total: 81 bytes
Signed-off-by: Sertonix <sertonix@posteo.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
When running `pgrep -x example` against a process `/bin/example --arg`,
BusyBox fails to match, while GNU pgrep succeeds. The reason is that the
comparison is done only against the full argv[0] rather than comm. This
patch changes pgrep -x to also try /proc/[pid]/comm for exact matching.
function old new delta
pgrep_main 681 670 -11
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Since commit 551bfdb97 (ls: implement -q, fix -w0, reduce startup
time) the '--color' option behaves as though the default argument
'always' had been specified.
This is due to an explicit short option for '--color' being given,
but without specifying that an argument is expected.
function old new delta
.rodata 106027 106029 +2
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
'\W' in PS1 returned an empty string for the root directory. bash
displays '/' in similar circumstances.
Avoid returning an empty string for the directory.
function old new delta
parse_and_put_prompt 873 883 +10
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The first login entry is ignored if a log file contains more than one
entry. To fix it, do not break the while loop if the offset is zero.
Signed-off-by: Dmitry Klochkov <dmitry.klochkov@bell-sw.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
aterm.png: 2477 -> 2303 (-174 bytes)
sterm.png: 1022 -> 774 (-248 bytes)
|
|
Convert the icons to PNG format (by simply exporting them from
GIMP and selecting the 'Compressed (PNG)' chackbox). Allow these
to be selected instead of ICO format at build time.
Use the PNG icons by default in the Unicode and aarch64 builds.
Saves 26KB in those cases.
(GitHub PR #540)
|
|
It also makes the version number within the manifest use the version
macros, replacing the hard-coded "6.0.0.0".
Unicode: 32668 -> 32188 (-480 bytes)
non-Unicode: 32412 -> 31956 (-456 bytes)
with icons included.
|
|
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)
|
|
Tweak the make_single_applets.sh script so it works for Windows
builds.
(GitHub issue #536)
|
|
function old new delta
busybox_main 695 734 +39
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
update_local_clock 872 951 +79
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Setting the console dimensions doesn't work reliably. Drop
support for the 'rows' and 'columns' settings.
Saves 752-768 bytes.
(GitHub issue #58)
|
|
Use the Gnulib implementation of flock(2) to allow the flock
applet to be enabled.
Costs 900-984 bytes.
(GitHub issue #528)
|
|
Use the (somewhat ancient) Microsoft RtlGenRandom() function to
provide random data for /dev/urandom.
Saves 176-240 bytes.
(GitHub issue #519)
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The '^C' displayed on interrupt should go directly to the console
to emulate the typical behaviour of the Unix tty driver.
Adds 16 bytes.
(GitHub issue #531)
|
|
The default configuration for Windows on ARM now:
- omits unwind tables;
- supports Unicode.
|
|
busybox cp refuses to overwrite another symlink to a directory due to
an incorrect stat() call that should be lstat(). When using -T, we want
to consider the target argument directly without resolving symlinks.
function old new delta
cp_main 496 514 +18
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Specifying a PID of 0 for the -p option of chrt would previously result
in a "number 0... not in range" error. Now, it means instead that the
calling process (i.e. chrt itself) should be operated on; this is to be
consistent with the behavior of util-linux's version of chrt.
function old new delta
chrt_main 462 474 +12
Signed-off-by: Zuo An <zuoan.penguin@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Remove the puts(cterm) call that was likely leftover debugging code.
The controlling terminal name is already properly displayed via the
'Controlling term:' label, so the raw terminal name output was redundant
and could cause issues when cterm is NULL.
Also add proper cleanup for the allocated cterm string.
function old new delta
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Currently vi in Busybox doesn't support filtering text through an
external command with ':1,2!cmd'. Instead it behaves as if no
range had been supplied and displays the output of the command.
Issue a warning and do nothing in such cases.
function old new delta
colon 3993 4010 +17
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
|
|
When the wait builtin detects an interrupt it should print '^C' to
stdout, as is done in other similar cases.
Saves 16 bytes in the 64-bit build.
|
|
Commit 387d01161 (ash: allow wait builtin to be interrupted)
allowed the wait builtin to be interrupted by ctrl-c. However,
this didn't work in the presence of a trap.
When waitpid_child() detects an interrupt propagate this up the
call stack so the wait builtin terminates and the trap is invoked.
Adds 80-88 bytes.
(GitHub issue #530)
|
|
Commit 64c8f5f3d0 (ash: add support for INT trap) didn't follow
upstream behaviour. If a trap is supplied for SIGINT, upstream's
signal handler detects this and doesn't call raise_interrupt().
The busybox-w32 implementation called raise_interrupt() but had it
do nothing.
Modify the code to match upstream's behaviour.
Saves 16-36 bytes.
|
|
After commit f6be217fa (ash: wait builtin should block) it wasn't
possible to interrupt a call to wait with Ctrl-C.
A blocking wait should be stopped from time to time to check for
an interrupt.
Adds 32 bytes.
(GitHub issue #529)
|
|
It was found that the 'wait' shell builtin would use 100% of a core
when waiting for a process to terminate:
sleep 60 &
wait
This is a regression caused by commit bb8f6b688 (ash: fix slow
running when background job is present). See the commit message
and GitHub issue #434 for the long and involved history.
The problem is in the Windows implementation of waitproc() in ash.
The 'block' argument to waitproc() can take three values:
DOWAIT_NONBLOCK
DOWAIT_BLOCK
DOWAIT_CHILD_OR_SIG
The first two have obvious meanings. The third performs a non-
blocking wait(2) and if no PID is returned it waits for SIGCHLD.
So in effect it's a blocking wait.
The Windows implementation would perform a non-blocking wait(2)
but couldn't then wait for SIGCHLD, because Windows doesn't have
such a signal. As a result the 'wait' builtin would loop calling
waitproc().
To avoid this DOWAIT_CHILD_OR_SIG should be treated as a blocking
wait in waitproc().
(GitHub issue #529)
|
|
Commit 6481bb22b (win32: use 64-bit time on 32-bit platforms) fails
to build with mingw32-gcc prior to mingw-w64 10.0.0.
Don't used 64-bit time for such builds.
mingw-w64 7.0.0 and below don't have some definitions required for
native TLS support. This is enabled by default in the 64-bit
Unicode build.
Add the definitions required for the default build. TLS 1.3
support needs more but isn't enabled by default.
(GitHub issue #527)
|
|
Recent versions of busybox-w32 rely on features which are only
available in contemporary versions of mingw-w64 and gcc.
Allow building on somewhat older toolchains.
(GitHub issue #527)
|
|
attacks
This fixes CVE-2025-46394 (terminal escape sequence injection)
Original credit: Ian.Norton at entrust.com
function old new delta
header_list 9 15 +6
header_verbose_list 239 244 +5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 11/0) Total: 11 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
We already fixed up errno when a directory was opened by open().
Do the same for fopen(). This allows grep to give a more useful
error message when it's asked to open a directory.
Adds 64 bytes.
(GitHub issue #521)
|
|
Currently vi in Busybox doesn't support filtering text through an
external command with ':1,2!cmd'. Instead it behaves as if no
range had been supplied and displays the output of the command.
Issue a warning and do nothing in such cases.
Adds 32 bytes.
(GitHub issue #524)
|