A mirror of https://github.com/rmyorston/busybox-w32.git https://git.lua4.win/busybox-w32/atom?h=stty 2016-08-03T14:50:00+00:00 2016-08-03T14:50:00+00:00 Ron Yorston rmy@pobox.com 2016-08-03T14:50:00+00:00 urn:sha1:1db2fafb1173038586cbb3d6673e1549a681c3fe The console buffer width is made to match the console width; the buffer height must always be greater than or equal to the number of rows in the console. 2016-08-02T14:53:24+00:00 Ron Yorston rmy@pobox.com 2016-08-02T14:53:24+00:00 urn:sha1:759188eae5651f1fbca45be310b0b9b46d876080 2016-07-08T07:50:16+00:00 Ron Yorston rmy@pobox.com 2016-07-08T07:50:16+00:00 urn:sha1:3ee1cc4e3986b74a7126871ad2a677b9e3ac3662 vsnprintf can return -1. I've seen it do this when writing to a small buffer while vsnprintf(NULL, 0, ...) returns a valid length. I'd prefer not to rely on the latter working with arbitrary old Windows runtimes so just skip ANSI emulation if -1 is returned. 2016-05-25T07:58:07+00:00 Ron Yorston rmy@pobox.com 2016-05-25T07:58:07+00:00 urn:sha1:204f9419baa815d3030ea618ddde5d05525c6c6c 2016-05-24T09:48:34+00:00 Ron Yorston rmy@pobox.com 2016-05-24T09:48:34+00:00 urn:sha1:0d5f85b255e68385b4aa1b6b8c40ab4b7ad35125 tail failed to process input from a pipe correctly: $ echo -n 54321 | tail -c 3 543 It was trying to use lseek as an optimisation but WIN32 lseek doesn't return an error whan applied to a pipe. Fix this by providing a wrapper for lseek. 2016-05-18T10:06:02+00:00 Ron Yorston rmy@pobox.com 2016-05-18T10:06:02+00:00 urn:sha1:c7c05c8e5723ed833ed0e73d24d7f7c45169c6e9 Previously spawn was returning a process handle which was treated as a pid in certain circumstances. This resulted in the following failing: find . -type f | sed xargs -n 1 sed -n '1 p' It should output the first line of each file but stopped after the first. 2016-05-18T07:43:42+00:00 Ron Yorston rmy@pobox.com 2016-05-17T07:29:14+00:00 urn:sha1:4988f3c4cc3cb9e8b1ccb06e84768c177cb13385 Make mingw_spawn_applet and mingw_spawn_1 static. The return value from spawnve is an exit code in synchronous mode and a process handle in asynchronous mode. Pass these upwards without interpretation. 2016-04-26T15:48:38+00:00 Ron Yorston rmy@pobox.com 2016-04-26T15:48:38+00:00 urn:sha1:248a2600a2f4b442101ad568d1994b908bb28d4b Recent changes to make the Windows console behave more like a *nix terminal didn't work too well for vi/less. On *nix the terminal buffer can't be scrolled while such screen-based applications are running. In the Windows console this remained possible and led to confusion. Add a new routine to allow vi/less to revert to their previous behaviour where the cursor is positioned at the top of the buffer and the entire buffer is cleared. 2016-04-26T15:45:09+00:00 Ron Yorston rmy@pobox.com 2016-04-26T15:45:09+00:00 urn:sha1:601f47a2ebcc54c995359c6f87e0eed932329e89 When a normal *nix terminal has been scrolled back through its buffer, any keypress will return to the cursor position. Add code to lineedit.c to do the same for the Windows console. 2016-04-26T15:40:18+00:00 Ron Yorston rmy@pobox.com 2016-04-26T15:40:18+00:00 urn:sha1:0d9e95c2dbc422ffa3db10132db3154357c461be Various tasks on the shell command line (e.g. backspace, DEL, reverse search) were found to be slow when the console screen buffer was very large. This was because the entire buffer was being cleared in erase_till_end_of_screen(). Rewrite erase_till_end_of_screen() to only clear to the end of the visible screen and to be tidier. (Based on a suggestion by GitHub user avih.) Also, modify move_cursor to use coordinates relative to the current display (as ANSI escapes expect) rather than relative to the screen buffer.