Re: 6k buffer bug in shells
Chet Ramey wrote: There have been several interesting discussions on this topic, most centered on Linux: https://groups.google.com/d/msg/linux.kernel/PYgS2MyNQfw/orRVLXtinOwJ http://lists.gnu.org/archive/html/bug-readline/2012-07/msg4.html http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00065.html http://lists.gnu.org/archive/html/bug-readline/2013-07/msg00013.html Seems most of those were 5-6 years ago. Might explain why I can't reproduce it, though I'm pasting into a remote TTY window in each case. (one SecureCRT, other xterm) -- w/about 290899 chars pasted. Only case I've seen of pasted chars being eaten is if the source code was indented with TAB... then various autocomplete prompts swallow chars randomly based on number of matching autocomplete entries. including the following comment: "So, after quite a lot of extra hours spent on this, we were able to track MOST of the breakage to this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f23eb2b2b28547fc70df82dd5049eb39bec5ba12"; Margarita Manterola and Maximiliano Curia did most of the work; here is the final summary of their findings (the subsequent thread is interesting as well): https://lkml.org/lkml/2013/7/25/205 The question is how to deal with large amounts of data in a situation where the tty modes keep getting changed after each newline, while preserving acceptable behavior for the usual case of cooked mode. Chet
Arithmetic expansion bug.
Description: There is a bug when expanding this math: $ echo "$((~0))" bash: /home/user: syntax error: operand expected (error token is "/home/user") It works correctly when an space is added: $ echo "$(( ~0 ))" -1 Bash version: $ echo "$BASH_VERSION" 4.4.12(1)-release Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-7fckc0/bash-4.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie -Wno-parentheses -Wno-format-security uname output: Linux IO.iafcg.priv 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release -- Cases are always threesome: Best case, Worst case, and Just in case
Incorrectly wrapped long utf8 PS1
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I./include -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -O2 -g -march=core2 -mtune=core2 -pipe -Wno-parentheses -Wno-format-security uname output: Linux blackspire2 4.4.39-gentoo #1 SMP PREEMPT Sat Jan 14 12:21:50 CET 2017 x86_64 Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release Description: A detailed report is at https://bugzilla.gnome.org/show_bug.cgi?id=787157. Initially, I thought it was a vte bug, but there it was established it's a problem in bash. The report was made with bash 4.3, but with 4.4, while there's an improvement (no longer breaks line inside utf8 sequence; though during retesting I think I've seen it truncate PS1 in the middle of the finishing escape sequence once, but wasn't looking at that then, so don't recall exact circumstances), the oddities in wrapping / cursor movement remain. Pure ASCII paths seem unaffected. Repeat-By: See the gnome bug.
