| Commit message (Collapse) | Author | Files | Lines |
|
The testsuite includes some Windows-specific tests. Exclude these
when running a test on a native build to avoid upsetting the results.
|
|
The shell detected a native Windows environment by checking for a
mixed-case 'Path' environment variable. This has always worked on
Windows but recent versions of Wine have a 'PATH' environment
variable.
Check also for 'ComSpec'.
Costs 24-48 bytes.
|
|
When the UTF-8 manifest is included in the binary but the ANSI
code page isn't UTF-8 report "UTF8 manifest not supported".
|
|
Make it possible to use the 'trap' built-in with command substitution,
process substitution and in pipelines.
Costs 200-256 bytes.
|
|
Move the code to handle the case nprocs == 1 from jobtab_size()
to procstat_size().
Saves 16 bytes.
|
|
|
|
|
|
Pass job data to child shells. This makes it possible to use
the 'jobs' built-in with command substitution, process substitution
and in pipelines.
Costs 576-672 bytes
(GitHub issue #350)
|
|
Allow nproc to build without error when LONG_OPTS is disabled.
|
|
The changes introduced to support the --binary option gave incorrect
results when comparing files with CRLF line endings *without* the
--binary option present.
The code needs to keep track of the position within the file and is
confused by text mode.
As an alternative solution, always use binary mode but skip the CR
of a CRLF pair when the --binary option isn't used. This gives
results matching GNU diff when comparing files with matching line
endings, with or without --binary. When line endings differ the
results aren't always the same.
Costs 32 bytes in the 32-bit build, saves 16 in 64-bit.
(GitHub issue #348)
|
|
|
|
Previously, when writing to the console, the non-unicode build always
assumed the source data is in the ANSI codepage, and used charToCon
to convert it unconditionally to the console CP.
Similarly, the unicode build made the same assumption (where ANSI CP
is UTF8), and always tried to convert it so that it's printed
correctly (at least when FEATURE_UTF8_OUTPUT is enabled - which it is
by default at the unicode build).
However, there could be cases where this assumption is incorrect, for
instance if the data comes from a file encoded for some codepage X,
and after the user also changed the console CP to X does 'cat file.X'
This commit allows disabling this conversion, using the same env vars
which can be used to disable the locale/unicode elsewhere, (LANG,
LC_CTYPE, LC_ALL as "C") e.g. 'LC_ALL=C cat file.X' now doesn't
convert, and the console renders it according to its own codepage.
|
|
Previously, the unicode build required console (out) codepage of UTF8
in order for unicode output to be printed correctly - e.g. at the
shell command prompt or the output of `ls` for unicode file names.
This is inconvenient, because by default it's not UTF8, and so unless
the user invoked 'chcp 65001' - by default unicode output didn't work.
This feature (which is now enabled for the unicode build) makes it
print unicode output correctly regardless of the console CP, by
using a new stream-conversion funcion from UTF8 chars to wchar_t,
and writing those using WriteConsoleW.
If the console CP happens to be UTF8 - this conversion is disabled.
We could have instead changed the console CP to UTF8, but that's
a slippery slope, and some old program which expect the default CP
might get broken, so achieving the same result without touching
the console CP is hopefully better.
|
|
Use one call to do both charToCon and then write it to the console.
Technically, this commit only reduces boilerplate code slightly,
but it also makes it easier for future modifications to make
changes to this sequence in one place.
|
|
When the UTF8 manifest is included in the binary and ACP isn't UTF8
fail at once. This avoids raising false hopes if the binary is run
on Window 7/8. On Windows XP it won't even run.
When the busybox applet is run without arguments always report the
build-time configuration of globbing and the UTF8 manifest.
|
|
|
|
When the UTF8 manifest is enabled at build time, then the version
now includes a string indicating whether unicode is active (e.g. it's
inactive on win 7/8, but should be active on Win10 1903+).
|
|
This adds the Emoticons block U+1F600..U+1F64F as double-width
codepoints, and the skin tone modifiers range U+1F3FB..U+1F3FF
as combining codepoints.
The Emoticons variant modifiers U+FE0E and U+FE0F were already in.
It's unclear how to test UNICODE_COMBINING_WCHARS and
UNICODE_WIDE_WCHARS in general and also here specifically,
but at least the data on Emojis width and combinings now exits.
|
|
Commit 8ade494 added VT input support and, among others,
disabled inc_cursor (in favor of the upstream busybox code) when
the terminal has VT input enabled.
However, inc_cursor works correctly regardless of the VT mode,
and that condition was not required.
Revert this condition (but still disable inc_cursor with unicode
because it handles wide-glyphs incorrectly).
|