Re: PROMPT_COMMAND causing strange cursor behavior

2015-04-28 Thread Martin Sebor

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

2015-04-27 Thread Martin Sebor

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 $()

2009-09-24 Thread Martin Sebor

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=$(catEOF
foo
bar
EOF)
Ctrl+D
-bash: unexpected EOF while looking for matching `)'
-bash: syntax error: unexpected end of file


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 $()

2009-09-23 Thread Martin Sebor

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 EOF
foo
bar
EOF)
Ctrl+D
-bash: unexpected EOF while looking for matching `)'
-bash: syntax error: unexpected end of file

Repeat-By:
Save the following script in a file named t.sh, execute the file
and observe the parse error:
./t.sh: line 7: unexpected EOF while looking for matching `)'
./t.sh: line 13: syntax error: unexpected end of file

#!/bin/bash
x=`cat EOF
foo
bar
EOF`

y=$(cat EOF
foo
bar
EOF)

[ $x != $y ]  exit 1