Re: PROMPT_COMMAND causing strange cursor behavior
On 04/28/2015 08:26 AM, Chet Ramey wrote: On 4/27/15 1:26 PM, Martin Sebor wrote: Bash Version: 4.3 Patch Level: 33 Release Status: release Description: When the PROMPT_COMMAND variable is set to a command such a printf it causes the cursor to jump to disappear or jump to the wrong positions when typing text that spans more than physical terminal line. The problem exists in at least Bash 4.2 and 4.3 (but likely earlier versions as well). This isn't exactly a bug. If readline doesn't know where the cursor is when it starts to perform redisplay, it's not going to be able to put the cursor in the right position. Readline assumes that cursor starts in column 0 and makes redisplay decisions based on that. Yes, I subsequently found a report of a similar problem here: http://lists.gnu.org/archive/html/bug-bash/2009-03/msg4.html It seems that PROMPT_COMMAND shouldn't (isn't intended to) be used for commands that produce output. If that's so, may I suggest to mention it in the manual? Otherwise, the trouble is that there are tools that use the variable for just that purpose. Thanks Martin
PROMPT_COMMAND causing strange cursor behavior
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-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux beacon 3.18.7-200.fc21.x86_64 #1 SMP Wed Feb 11 21:53:17 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.3 Patch Level: 33 Release Status: release Description: When the PROMPT_COMMAND variable is set to a command such a printf it causes the cursor to jump to disappear or jump to the wrong positions when typing text that spans more than physical terminal line. The problem exists in at least Bash 4.2 and 4.3 (but likely earlier versions as well). Repeat-By: 1) Open a terminal window (either XTerm or GNOME Terminal) 80 columns wide. (The exact width shouldn't matter.) 2) Either set the TERM variable to vt100 or xterm, or unset it. The setting doesn't eliminate the problem but tends to have a slightly different effect on how it manifests. 3) Set the PROMPT_COMMAND variable to a string such as "printf '123: '" and unset PS1 (the second part isn't necessary to reproduce the problem). 4) Observe the shell prompt and the cursor after the trailing space: "123: " 5) If using GNOME Terminal, type as many characters as necessary for the cursor to advance to the last column of the terminal window. Then type one more character and observe the cursor disappear. (It doesn't seem to disappear in XTerm.) 6) In either terminal proceed to type more characters. The line will wrap around, continuing in column 1. Before the cursor advances to line up with the first typed character on the line above, observe it jump to column 1. 7) Continue typing more characters and observe the text overwrite the previously typed and displayed characters. 8) Enter ctrl+a to move the cursor to the beginning of the typed line and observe it jump into the middle of the prompt instead to the beginning of the typed text.
Re: bash 4 parse error on here-document in $()
Thank you for setting me straight! I had checked the POSIX spec before sending the report but missed the part about the delimiter having to be immediately followed by newline. Martin On 09/24/2009 06:39 AM, Chet Ramey wrote: Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: Bash 4.0 errors on a here-document enclosed in $(). For example: x=$(cat< The shell is allowed to do this. A here-document is supposed to be terminated by a line containing the delimiter followed by a newline, not EOF. However, the behavior is useful enough that I changed the parser to support it in bash-4.1. Chet
bash 4 parse error on here-document in $()
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables uname output: Linux mslaptop 2.6.30.5-43.fc11.i586 #1 SMP Thu Aug 27 21:18:54 EDT 2009 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: Bash 4.0 errors on a here-document enclosed in $(). For example: x=$(cat <
