| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous commit prevented the console from crashing with a
UTF8 input code page on Windows 10/11 in the default configuration.
But it broke input in CJK code pages. Again.
Handle both cases.
Costs 36-72 bytes.
(GitHub issue #335)
|
| |
|
|
|
|
|
|
| |
Although the input method used for euro support is no longer
required for that reason it does provide a more lightweight
workaround for the problem with ReadConsoleInputA and UTF8.
Repurpose FEATURE_EURO_INPUT as FEATURE_UTF8_INPUT.
|
| |
|
|
|
|
|
| |
Move decision about how to read console input from windows_read_key()
to readConsoleInput_utf8().
Saves 48-64 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 597d31ee (EURO_INPUT), ReadConsoleInputA is the default.
The main problem with that is that if the console codepage is UTF8,
e.g. after "chcp 65001", then typing or pasting can result in a crash
of the console itself (the Windows Terminal or cmd.exe window closes).
Additionally and regardless of this crash, ReadConsoleInputA is
apparently buggy with UTF8 CP also otherwise.
For instance, on Windows 7 only ASCII values work - others become '?'.
Or sometimes in Windows 10 (cmd.exe console but not Windows terminal)
only key-up events arrive for some non-ASCII codepoints (without
a prior key-down), and more.
So this commit implements readConsoleInput_utf8 which delivers UTF8
Regardless of CP, including of surrogate pairs, and works on win 7/10.
Other than fixing the crash and working much better with UTF8 console
CP, it also allows a build with the UTF8 manifest to capture correctly
arbitrary unicode inputs which are typed or pasted into the console
regardless of the console CP.
However, it doesn't look OK unless the console CP is set to UTF8
(which we don't do automatically, but the user can chcp 65001),
and editing is still lacking due to missing screen-length awareness.
To reproduce the crash: start a new console window, 'chcp 65001', run
this program (or busybox sh), and paste "ಀ" or "😀" (U+0C80, U+1F600)
#include <windows.h>
int main() {
HANDLE h = GetStdHandle(STD_INPUT_HANDLE);
INPUT_RECORD r;
DWORD n;
while (ReadConsoleInputA(h, &r, 1, &n)) /* NOP */;
return 0;
}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, console input was converted to the ANSI codepage using
OemToChar[Buff], and ANSI to console conversion used CharToOem[Buff].
However, while typically true by default, it's not guaranteed that
the console CP is the same as the OEM CP.
Now the code uses the console input/output CP as appropriate instead
of the OEM CP. It uses full wide-char conversion code, which was
previously limited to FEATURE_EURO, and now may be used also otherwise.
While at it, the code now bypasses the conversion altogether if the
src/dst CPs happen to be identical - which can definitely happen.
Other than saving some CPU cycles, this also happens to fix an issue
with the UTF8 manifest (in both input and output), because apparently
the Oem/Char conversion APIs fail to convert one char at a time (which
is not a complete UTF8 codepoint sequence) even if both the OEM and
the ANSI CPs are UTF8 (as is the case when using UTF8 manifest).
Conversion is also skipped:
- if the converted output would be longer than the input;
- if the input length is 1 and the input is multi-byte.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 93a63809f (win32: add support for the euro currency symbol)
made various changes to enable support for the euro symbol.
One of these changes allows the euro to be entered from the console
even if the current code page doesn't support it. This is probably
of limited use: the symbol can be entered but won't be displayed
correctly.
Move this capability into a separate configuration option,
FEATURE_EURO_INPUT, which is disabled by default.
Saves 48-64 bytes in the new default case.
(GitHub issue #335)
|
| |
|
|
|
|
|
|
|
|
|
| |
- Disable ENABLE_PROCESSED_INPUT in raw mode. Otherwise ^C isn't
immediately detected during shell command line editing with
virtual terminal input enabled.
- Switch read_key()/unix_readkey() to windows_read_key()/read_key().
This allows the shell `read` builtin to use windows_read_key().
Without this change `read` fails when virtual terminal input is
enabled.
|
| |
|
|
|
|
|
| |
Until now busybox-w32 has used a native Windows implementation
of read_key(). Build the upstream Unix implementation and use
it instead of the native version when virtual terminal input
mode is enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Modify `struct termios` to support Windows virtual terminals.
Native console mode flags replace the Unix `c_?flag` structure
members. Remove unsupported flags from termios.h.
Add implementations of tcgetattr(3)/tcsetattr(3) to get/set console
flags when virtual terminal input mode is enabled.
Add support for emulating raw mode to get_termios_and_make_raw().
This (and related functions) are exposed but not yet used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The WIN32 implementation of read_key() didn't reset errno to zero,
unlike the upstream version. This could result in invalid non-zero
errno values after calls to lineedit_read_key().
For example, after an attempt to run a non-existent command in the
shell errno is set to ENOENT. If the shell had vi line edit mode
enabled any command that reads an additional character (e.g. 'c' or
'd') would see the non-zero errno and report EOF.
(GitHub issue #283)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In read_keys():
- Identify all keys on the numeric pad used to enter character
codes. Otherwise Alt-Left/Alt-Right on the numeric pad are
treated as word movements in command line editing, preventing
the entry of character codes containing 4 or 6.
- Add modifier flag bits to the virtual keycodes we care about.
This means, for example, that only the unmodified Up/Down arrow
keys move through shell history, not Up/Down plus arbitrary
modifiers.
|
| |
|
|
| |
No change in functionality. Saves 16 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7874ca73b (win32: allow characters to be entered as ALTNNN)
made it possible to enter characters using Alt and a character code
on the numeric pad. This required detecting the release of the
Alt key.
Sometimes this caused a problem when using Alt+Tab to cycle between
applications. If Alt was released before Tab the code passed a tab
character to the application.
Avoid such issues by looking specifically for the release of the Alt
key.
|
| |
|
|
|
|
|
|
|
|
| |
This patch restores support for Bash-stle Alt commands present in the
original BusyBox:
* Alt-b, Alt-LeftArrow backward word
* Alt-f, Alt-RightArrow forward word
* Alt-BackSpace delete word backward
* Alt-d delete word forward
|
| |
|
|
|
|
|
|
|
|
|
| |
When a path name is copied to a console application using drag and
drop the path separator is backslash. To handle this situation in
the shell add an editing command (Ctrl-Z) to convert all backslashes
on the current line to slashes.
See GitHub issue #149.
Also remove some unused code from read_key().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The euro currency symbol was added to some OEM code pages. See:
https://www.aivosto.com/articles/charsets-codepages-dos.html
Add a configuration option (enabled by default) to support this.
When enabled:
- The read_key() function requests wide character key events. This
allows the euro symbol to be entered regardless of the console OEM
code page, though it needs to be available in the ANSI code page.
- Conversions between OEM and ANSI code pages in winansi.c are
modified to work around a bug in the Microsoft routines.
- If the OEM code page is 850 when BusyBox starts it's changed to
858. This is the only currently supported OEM code page.
Also, the shell read builtin is modified to use read_key() whenever
input is being taken from the console.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It wasn't possible to enter characters using Alt and the decimal
character code. This was because the character is generated when
the Alt key is released but the WIN32 implementation of read_key()
ignored all key up events.
Modify read_key() to ignore numbers entered on the numeric keypad
with Alt pressed and to detect when Alt is released.
Fixes GitHub issue #136.
|
| |
|
|
|
| |
The code to manipulate terminal settings serves no purpose in WIN32.
Use conditional compilation to exclude much of it.
|
| |
|
|
|
|
| |
Move the wait for timeout into the while loop of read_key. Otherwise
the timeout won't be checked after any event that doesn't result in
a value being returned.
|
| | |
|
| |
|
|
|
|
| |
It seems that passing control characters through OemToCharBuff is
not a good idea: some of them end up in the top half of the
codepage.
|
| |
|
|
|
|
|
|
|
|
| |
Windows console applications use different codepages for console I/O
and the rest of the API:
http://msdn.microsoft.com/en-us/goglobal/bb688114.aspx#E2F
Attempt to workaround this by converting characters when they're read from
and written to the console. Not all possible paths are handled.
|
| | |
|
| | |
|
| |\ |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
will be needed by CONFIG_FEATURE_VI_ASK_TERMINAL
|
| | |/
|/|
| |
| |
| |
| | |
This makes ^C and ^D work properly regarding ash input handling
(i.e. does not crash ash). Pressing ^C in ash does not stop running
programs though.
|
| | | |
|
| | |
| |
| |
| |
| | |
-1 to lineedit means error... when tty is destroyed... it would
terminate ash for some reasone
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
