aboutsummaryrefslogtreecommitdiff
path: root/win32 (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* ps: report unknown parent PID as 1Ron Yorston2024-05-141-2/+20
| | | | | | | | | | 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)
* kill: killing a zombie process should failRon Yorston2024-05-141-106/+90
| | | | | | | | | | | | | | | | | | | | | | | 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)
* win32: try to avoid downloading offline filesRon Yorston2024-04-301-2/+5
| | | | | | | | It's possible that files in remote storage may not be available locally. Avoid downloading such files just to obtain file attributes. (GitHub issue #414)
* win32: adjust handling of executable extensionsRon Yorston2024-04-221-8/+12
| | | | | | | | | | | | | | | Mixing Windows and Unix-style filename extensions was causing problems. Tweak how extensions are handled to try and improve matters: - Consistently check whether the unaltered filename is an executable before trying adding extensions. - Check .exe and .com before .sh. Saves up to 16 bytes. (GitHub issue #405)
* win32: make stat(2) fail for /dev/zero, /dev/urandomRon Yorston2024-04-201-1/+2
| | | | | | | | | | /dev/zero and /dev/urandom are only available internally and as arguments to 'dd'. Since users can't otherwise access them they shouldn't be treated as existing by stat(2). With this change stat(1) and test(1) will deny their existence. (GitHub issue #282)
* ash: add title built-inRon Yorston2024-04-091-2/+6
| | | | | | | | | | | | | | 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)
* win32: ascii-optimize winansi_fputc, winansi_putcharAvi Halachmi (:avih)2024-04-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | Other winansi IO wrappers, like winansi_fputs, optimize by calling the libc API directly if no special handling is needed, e.g. if the input is fully ASCII and without escape sequences - without converting the output codepage or interpreting escapes. Now the fputc and putchar wrappers do that as well. And as a simplification, putchar is now also a wrapper of fputc. Other than possibly minor speedup, this can also help buffered streams remain buffered, because the codepage conversion using writeCon_utf8 is unbuffered and first flushes the stream, so by avoiding the conversion and calling the libc API directly, we also avoid premature flush of a buffered stream. This did happen, as "time" is buffered since commit 54dbf0fa5, so previously it was flushed early when using putchar, while now it remains buffered by default (but can still be flushed early if the -f format string contains non-ASCII chars).
* win32: UTF8_OUTPUT: flush stream before conversionAvi Halachmi (:avih)2024-04-061-1/+3
| | | | | | | | | | | | | | | | | | | | writeCon_utf8 is unbuffered - it writes directly using WriteConsoleW, but some winansi libc IO wrappers, like fputs, use the libc API directly if the content doesn't need any special handling (e.g. all ASCII and no escape sequences), and so if the stream is buffered, and if only some parts of it go through writeCon_utf8, then we can get wrong output order due to some parts being buffered and some not. Case in point, the recent commit 54dbf0fa5 made the output of "time" buffered, and so if only parts of it go through writeCon_utf8, then we get bad output order. This did actually happen, because not all the winasi wrappers have this ASCII-only optimization (e.g. winansi_putchar), and "time" did end up with wrong output order. Even if all the winansi wrappers were ASCII-optimized, "time" could still have unicode output, e.g. with -f. Fix it by flushing the stream before converting using writeCon_utf8.
* win32: improvements to realpath(3)Ron Yorston2024-03-091-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The previous commit unnecessarily duplicated the path returned from resolve_symlinks(), resulting in a memory leak. Thanks to avih for spotting this. Even if we can't canonicalise the path in resolve_symlinks() we can at least return the result of resolving the trailing symlink. Moreover, this can be done both when the necessary API is missing and when the filesystem doesn't support it. Not perfect, but better than nothing, and there's no cost. This change gets rid of a handful of realpath-related test failures on ReactOS and Windows XP. Some background: Commit 8ebe81483 returned the raw path when the required API was missing. This was reverted in commit f902184fa because it caused an infinite loop (GitHub issue #204). Commit 31467ddfc fixed the cause of the loop, which is why it's now safe to reintroduce a fallback return. (GitHub commit #389)
* win32: let realpath(3) work on flaky filesystemsRon Yorston2024-03-081-0/+3
| | | | | | | | | | | | Some filesystems don't support the feature required to resolve symlinks for realpath(3). In such cases just carry on without resolving symlinks. This is a trade-off between correctness and convenience. Adds 16 bytes. (GitHub issue #389)
* win32: fix uname(2) if ARM architecture is undefinedFRP-5301-gda71f7c57Ron Yorston2024-02-201-0/+2
| | | | | Older versions of mingw don't define PROCESSOR_ARCHITECTURE_ARM64. Don't let this stop the build.
* win32: avoid console windows from CGI scriptsRon Yorston2024-02-071-1/+1
| | | | | | | | | When httpd is run in the background its processes are detached from the console. CGI scripts could create subprocesses which needed a console, resulting in annoying console windows appearing. Prevent this by changing the creation flags for CGI scripts to CREATE_NO_WINDOW.
* win32: UTF8_OUTPUT: recover quicker from bad byteAvi Halachmi (:avih)2024-01-311-12/+19
| | | | | | | | | | | | | | | | | | | | | | When an unexpected value is detected in UTF-8, we should print the placeholder codepoint, and then recover whenever we detect a value which is valid for starting a new UTF-8 codepoint (including ASCII7). However, previously, we only tested recovery at the bytes following the unexpected one, and so if the first unexpected value was also valid for a new codepoint, then didn't rcover it. Now we check for recovery from the first unexpected byte, which, if recoverable, requires both placeholder printout and recovery, so the recovery "unwinding" is modified a bit to allow placeholder. Example of of a sequence which now recovers quicker than before: (where UTF-8 for U+1F600 "😀" is: 0xF0 0x9F 0x98 0x80) printf "\xF0\xF0\x9F\x98\x80A" Previously: ?A Now: ?😀A
* win32: import dirname(3) from mingw-w64Ron Yorston2024-01-302-0/+288
| | | | | | | | | | | | | The mingw-w64 project has updated its implementation of dirname(3). In some circumstances the new version doesn't preserve the type of the user-supplied top-level directory separator. As a result of this the dirname-handles-root test case failed. Import the new implementation and tweak it to preserve the type of the separator. This only affects mingw-w64 versions 12 and above. Currently only the aarch64 build using llvm-mingw is affected.
* win32: hardcode numeric value of MANIFEST resourceRon Yorston2024-01-231-2/+3
| | | | | It seems windres in llvm doesn't understand MANIFEST resources. Use the numeric value 24 instead.
* win32: add aarch64 to uname(2)Ron Yorston2024-01-211-0/+3
| | | | | For Windows on ARM we need to report the aarch64 processor architecture.
* build system: more clang/llvm tweaksRon Yorston2024-01-182-3/+0
| | | | | | | | | | | | | | | | | | Linkers associated with clang/llvm may not support the -r option. This is used to create built-in.o object files. It turns out that all such files in busybox-w32 are either empty or only contain one object file. The first case is already supported and the second can be handled by simply copying the object file to built-in.o. The linker is therefore never invoked with the -r option. One adjustment is required: the workaround adopted for GitHub issue #200 linked the dummy C file with the resource object file. This is no longer done so only one object file is used. Since it was the linking that broke the resource file, copying it is an equally effective fix for the issue. Some old linkers don't support the --warn-common option. The lack of this option was being detected but it was still sometimes used.
* win32: fix detection of directories in stat(2)Ron Yorston2024-01-041-3/+5
| | | | | | | | | | | | | | | | The implementation of stat(2) detected whether a pathname ending with a directory separator was valid by checking for the error code ERROR_INVALID_NAME when GetFileAttributesExA() failed. This works if the path refers to an actual disk but not if it's on a share. In the latter case the glob '*/' incorrectly returned files that weren't directories. Add code to handle this case. Costs 16-32 bytes. (GitHub issue #381)
* win32: code shrink procps_scan()Ron Yorston2023-12-311-2/+2
| | | | | | Use getpid() instead of GetProcessId(GetCurrentProcess()). Saves 16 bytes.
* httpd: consistently leak memory, or notRon Yorston2023-12-311-3/+8
| | | | | | | | | | | | | create_detached_process() is only used when running a CGI script. Previously it leaked the return values from quote_arg() but freed the command line it built. Whether or not the CGI script is successfully run its parent process exits almost immediately, so there's no pressing need to free the memory. If FEATURE_CLEAN_UP is disabled (which it is by default) don't bother. Saves 16 bytes.
* win32: fix clang error/warningRon Yorston2023-12-311-3/+3
| | | | | | | | | | | | Since clang doesn't seem to know about ffs(3) make it use __builtin_ffs() instead. Fix a warning in process_escape() in winansi.c: result of comparison of constant -1 with expression of type 'WORD' (aka 'unsigned short') is always true. Change the error value returned by process_colour() from -1 to 0xffff. Costs 16 bytes.
* httpd: enable support for CGIRon Yorston2023-12-201-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | The upstream code uses fork/exec when running a CGI process. Emulate this by: - Spawning a child httpd process with the special '-I 0' option, along with the options provided on the server command line. This sets up the proper state then calls the cgi_handler() function. - The cgi_handler() function fixes the pipe file descriptors and starts another child process to run the CGI script. These processes are detached from the console on creation. When spawn() functions are run in P_DETACH mode they don't connect to the standard file descriptors. Normally this doesn't matter but the process which runs the CGI scripts needs to inherit the pipe endpoints. The create_detached_process() function handles this. See: https://github.com/rprichard/win32-console-docs/blob/master/README.md Adds about 2.9Kb to the size of the binary. (GitHub issue #266)
* win32: code shrink execve(2) implementationRon Yorston2023-12-181-2/+2
| | | | | | | | | | | Commit 6d6856355a (win32: handle -1 return status from execve(2)) added a test of errno to distinguish between failure to run a program and the program returning -1. Subsequent changes in commit 9db9b34ada (win32: ignore ctrl-c in parent of execve(2)) make this test unnecessary. Remove it. Saves 16-32 bytes.
* httpd: fix return code when run in backgroundRon Yorston2023-12-151-11/+5
| | | | | | | | | | | When httpd was run in the background the return code of the parent process was incorrect. It seems when spawn() is run in _P_DETACH mode it returns 0 on success, not a process handle. Fix the test for the return code and alter mingw_spawn_detach() so it doesn't treat the return from spawn() as a handle. Saves 32 bytes.
* win32: only search PATH for compressorRon Yorston2023-11-141-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | mingw_fork_compressor() uses CreateProcess() to run the compressor program. This will often be an instance of BusyBox, but since the xv and lzma applets in BusyBox don't support compression it can be an external program. It was intended that the external program should be found using PATH. However, CreateProcess() looks in various other places before trying PATH. In particular, it first looks in the directory of the current executable, then in the current directory of the process. This can result in the wrong xz.exe or lzma.exe being found. Perform an explicit PATH search and force CreateProcess() to use the result. This change only affects the search for a compressor. The same problem also affects other uses of our popen(3) emulation. These may be addressed in future. Costs 64-80 bytes. (GitHub issue #376)
* win32: avoid terminal weirdness induced by GradleRon Yorston2023-10-241-2/+2
| | | | | | | | | | | | Commit 87a3ddc06 (win32: avoid terminal weirdness induced by Gradle?) correctly diagnosed the problem but got the cure wrong. Reset DISABLE_NEWLINE_AUTO_RETURN in the new mode, not the old one. Otherwise the change isn't applied. Saves 48 bytes. (GitHub issue #372)
* win32: avoid terminal weirdness induced by Gradle?Ron Yorston2023-10-221-0/+2
| | | | | | | | | | | | GitHub issue #372 reports that in certain circumstances (which I've been unable to reproduce) Gradle leaves the terminal in a state where linefeeds seem not to result in a carriage return. This *might* be because Gradle sets DISABLE_NEWLINE_AUTO_RETURN in the terminal mode. Reset DISABLE_NEWLINE_AUTO_RETURN to zero before the shell prompt is issued to see of this makes any difference. Costs 16-32 bytes.
* win32: fix handling of relative pathsRon Yorston2023-10-041-12/+3
| | | | | | | | | | | | | | Commit 548ec7045b (win32: interpret absolute paths as relative to %SYSTEMDRIVE%) introduced the function xabsolute_path() to make relative paths absolute. This is used in 'dkpg' and 'man' to avoid having to tinker with absolute paths from upstream. Unfortunately, it's too eager to use the relative path. This results in dpkg failing to install deb files with a relative path. Saves 32-48 bytes. (GitHub issue #371)
* sort: add support for sorting version stringsRon Yorston2023-10-012-0/+63
| | | | | | | | | | | Add an implementation of strverscmp from musl so that the 'sort -V' option works. Add '-V' to the trivial usage message. Costs 248-256 bytes. (GitHub issue #370)
* win32: missing support for "app exec link" reparse pointsRon Yorston2023-09-181-1/+2
| | | | | | | | | | Commit 603af9bb9 (win32: support "app exec link" reparse points) added support for IO_REPARSE_TAG_APPEXECLINK reparse points by pretending they're symbolic links. One change was missed, in the implementation of dirent. Costs 16 bytes.
* win32: improved support for manifestsRon Yorston2023-09-144-0/+50
| | | | | | | | | | The UTF-8 manifest has been updated to include features from the standard application manifest. Include a copy of the standard application manifest for toolchains that don't provide one. (GitHub issue #366)
* win32: convert exit codesRon Yorston2023-09-142-8/+36
| | | | | | | | | | | | | | | | | Add two utility functions to convert Windows process exit codes. - exit_code_to_wait_status() converts to a POSIX wait status. This is used in ash and the implementations of system(3) and mingw_wait3(). - exit_code_to_posix() converts to a POSIX exit code. (Not that POSIX has much to say about them.) As a result it's possible for more applets to report when child processes are killed as if by a signal. 'time', 'drop' and 'su -W', for example. Adds 64-80 bytes.
* make: return non-zero exit status when a command failsRon Yorston2023-09-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a build command returned a non-zero exit status 'make' reported a warning and returned an exit code of zero. This was due to the misuse of the status returned by system(3). As the man page says: the return value is a "wait status" that can be examined using the macros described in waitpid(2). (i.e., WIFEXITED(), WEXITSTATUS(), and so on). Use the error() function to correctly report the problem on stderr and return an exit status of 2. Some additional changes in the same area: - When a target is removed report the diagnostic on stderr, as required by POSIX. - When a build command receives a signal GNU make removes the target. bmake doesn't and it isn't required by POSIX. Implement this as an extension. - Expand the error message when a build command fails so it includes the exit status or signal number, as obtained from the value returned by system(3). - Alter the WIN32 implementation of system(3) to handle exit codes which represent termination as if by a signal. Adds 200-240 bytes. (GitHub issue #354)
* win32: UTF8_INPUT: fix combining of some surrogates pairsAvi Halachmi (:avih)2023-09-111-1/+1
| | | | | | | | | The construction of a codepoint from a surrogates pair was incorrect when the result should have had the 0x10000 bit unset, due to logical "|" instead of arithmetic "+" of 0x10000 (so the 0x10000 bit was set incorrectly when the result should have been U+[1]{0,2,4...C,E}XXXX). For instance: typing or pasting U+20000 ð €€
* Merge pull request #355 from avih/utf8-output-speedupRon Yorston2023-08-251-2/+8
|\ | | | | win32: UTF8_OUTPUT: speedup for big outputs
| * win32: UTF8_OUTPUT: speedup for big outputsAvi Halachmi (:avih)2023-08-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the native Windows console, writeCon_utf8 which converts a stream of UTF8 into console output is about 1.4x slower for big unicode writes than the native fwrite (e.g. when the console codepage is UTF8), which is not too bad. However, newer versions of conhost are quicker, e.g. OpenConsole.exe (which is conhost) which ships with the Windows terminal is about 4x faster than the native conhost in processing (unicode?) input. And when conhost can process inputs much quicker, it turned out that fwrite throughput was nearly 3x better than writeCon_utf8. Luckily, this turned out to be mainly due to the internal 256 wide chars buffer which writeCon_utf8 uses, and that with 4096 buffer it becomes only ~ 10% slower than fwrite, which is much better. However, making the console window very small such that it needs to spend very little time on rendering, makes it apparent that there's still a difference - writeCon_utf8 is about 30% slower than fwrite, but that's still not bad, and that's also an uncommon use case. So this commit increases the buffer, and also allocates it dynamically (once) to avoid abusing the stck with additional 8K in one call.
* | make: fix POSIX buildRon Yorston2023-08-241-2/+1
|/ | | | | | | | If upstream BusyBox had a 'make' applet a native build with it enabled should match the corresponding build from the busybox-w32 source. Make it so.
* win32: replace readlink(2)Ron Yorston2023-08-211-11/+15
| | | | | | | | | | | | | | | The Windows implementation of readlink(2) has caused problems in the past. As, for example, with commit c29dc205d2 (win32: fix implementation of readlink(2)). Most uses of readlink(2) in BusyBox are actually calls to the (considerably more convenient) library function xmalloc_readlink(). Implement a Windows version of that and used it instead of readlink(2). This improves the handling of symbolic links (and similar reparse points) in CJK and UTF-8 code pages. Saves 48-80 bytes.
* ash: detect console state on shell start upnoconsole2Ron Yorston2023-08-201-14/+0
| | | | | | | | | | | Set 'noconsole' to match the actual state of the console (normal/ iconified) when the shell is started. Thus ShowWindow() will only be called if the actual state differs from the default or user defined state. Costs 20-24 bytes. (GitHub issue #325)
* win32: disable console output conversion with LC_ALL=CAvi Halachmi (:avih)2023-08-031-6/+29
| | | | | | | | | | | | | | | | | | | | 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.
* win32: add FEATURE_UTF8_OUTPUT (enabled with unicode)Avi Halachmi (:avih)2023-08-031-0/+96
| | | | | | | | | | | | | | | | | | | | | 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.
* win32: unify 'convert and write to console' (no-op)Avi Halachmi (:avih)2023-08-031-17/+44
| | | | | | | | 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.
* win32: support build with FEATURE_UNICODE_SUPPORTAvi Halachmi (:avih)2023-07-221-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FEATURE_UTF8_MANIFEST enables Unicode args and filenames on Win 10+. FEATURE_UTF8_INPUT allows the shell prompt to digest correctly Unicode strings (as UTF8) which are typed or pasted. This commit adds support for building with FEATURE_UNICODE_SUPPORT (mostly by supporting 32 bit wchar_t which busybox expects): - Unicode-aware line-edit - for the most part cursor movement/del being (UTF8) codepoint-aware rather than assuming that one-byte equals one-char-on-screen. - Codepoint-aware operations in some other utils, like rev or wc -c. - When UNICODE_COMBINING_WCHARS and UNICODE_WIDE_WCHARS are enabled, some screen-width-aware operations, like with fold, ls, expand, etc. The busybox Unicode support is incomplete, and even less so with the builtin libc replacement functions, like wcwidth, which are active when UNICODE_USING_LOCALE is unset (mingw lacks those functions). FEATURE_CHECK_UNICODE_IN_ENV should be set so that Unicode is not hardcoded but rather depends on the ANSI codepage and some env vars: LC_ALL=C disables Unicode support, else it's enabled if ACP is UTF8. There's at least one known issue where the tab-completion-prefix-case is not updated correctly, e.g. ~/desk<tab> completes to ~/desktop/ instead of ~/Desktop/, because the code which handles it exists only at the non-unicode code paths, but that's not very critical. That seems to be the only case where mingw-specific code is disabled when Unicode is enabled, but there could be other unknown issues. None of the Unicode options is enabled by default, and the next commit will make it easier to create a build which supports Unicode.
* win32: UTF8 input: improve missing-key-down hackAvi Halachmi (:avih)2023-07-211-11/+47
| | | | | | | | | | | | | | The UTF8 input code works around an issue when pasting at the windows console (but not terminal) that sometimes we get key-up without a prior matching key-down - at which case it generates down. However, previously it detected this by comparing an up-event to the last down-event, which could result in false-positive in cases like: X-down Y-down X-up Y-up (e.g. when typing quickly). Now it remembers the last 8 key-down events when searching a prior matching key-down, which fixes an issue of incorrect repeated keys (in the example above Y-up was incorrectly changed to Y-down).
* win32: avoid crashing the console with poll(2)Ron Yorston2023-07-171-1/+1
| | | | | | | | | | | | | | | Commit 8e6991733 (ash: fix 'read' shell built-in (1)) introduced the use of poll(2) in the shell 'read' built-in. When the UTF8 code page is in use this results in the console crashing if a 3 or more byte UTF8 character is entered. The crash is caused by the use of PeekConsoleInputA() which, like ReadConsoleInputA(), is broken. It can be avoided by using PeekConsoleInputW() instead. The number of key events will differ but this doesn't matter in this case as poll(2) effectively runs in a busy loop with a 1ms sleep.
* date: allow system date to be setRon Yorston2023-07-161-0/+23
| | | | | | | | | Implement clock_settime(2) and enable the '-s' option to allow the system time to be set. This requires elevated privileges. The code in date.c is now identical to upstream BusyBox. Costs 256-272 bytes.
* ash: fix 'read' shell built-in (2)Ron Yorston2023-07-121-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | Enabling polling in the previous commit resulted in the following incorrect behaviour: { echo -n te; sleep 3; echo st; } | (read -t 1 x; echo "$x") An empty "$x" is echoed immediately, not after 1 second. { echo -n te; sleep 1; echo st; } | (read -t 3 x; echo "$x") An empty "$x" is echoed immediately. "test" should be echoed after 1 second. This arises because poll(2) from gnulib is unable to handle anonymous pipes properly due do deficiencies in Microsoft Windows. These have been acknowledged and fixed in relation to select(2): https://lists.gnu.org/archive/html/bug-gnulib/2014-06/msg00051.html Apply a similar fix to poll(2). Costs 104-156 bytes.
* ash: properly echo console input to 'read' built-inRon Yorston2023-07-121-0/+11
| | | | | | | The 'read' shell built-in echoed console input to stdout. Echo directly to the console instead. Costs 124-136 bytes.
* win32: more console input character conversionsRon Yorston2023-07-071-0/+20
| | | | | | | | | | | | | Add wrappers for the following input functions with conversions for console input. Applications suitable for testing these changes are appended in brackets. - getchar (xargs) - fgetc (tac) - getline (shuf) - fgets (rev) Costs 112-120 bytes.
* win32: character conversion for fread(3)Ron Yorston2023-07-061-0/+15
| | | | | | | Some applets use fread(3): dd and od, for example. Perform the necessary conversion when input is coming from the console. Costs 96-112 bytes.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-09-03 04:12:27 +0000