Re: 2 regressions related to PROMPT_COMMAND

[Chet Ramey]

smallnow wrote:
> 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-unknown-linux-gnu'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/a/local/share/locale'
> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include
> -I./lib   -g -O2
> uname output: Linux ul 2.6.27-12-generic #1 SMP Thu Feb 5 09:26:42 UTC
> 2009 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
> 
> Bash Version: 4.0
> Patch Level: 0
> Release Status: release
> 
> Description:
> Neither of these happen on the same system with 3.2.39(1)-release.
> 
> Bug #1:
> do:
> PROMPT_COMMAND='$(cd)'
> Then do anything that would change your prompt, for example change
> directories when PS1 contains the current directory. You will see the
> prompt will never update when PROMPT_COMMAND contains any command
> substitution. It just remains whatever it was when this was set. I used
> $(cd) as a trivial command substitution, but any command substitution
> seems to have the same effect.
> 
> I actually had some useful code including parameter expansions going on
> in my PROMPT_COMMAND. This took quite a while to figure out.

I attached a patch that should fix this.  The patch is a combination of
the fixes in

http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00183.html
and
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00221.html


> Bug #2:
> do:
> PS1=
> PROMPT_COMMAND='echo -ne $PWD'
> press up, then down.
> This brings up the last history and then goes to the new command again.
> The cursor goes goes to the beginning of the line screwing up text from
> PROMPT_COMMAND. This also happens with vi-mode commands. I put PS1= so
> that it doesn't confuse the issue, but that is not necessary.

You can't really call this a regression or a bug.  The readline redisplay
code, when it redraws after ^N, decides that it's faster to redraw the
whole line if the differences between the two lines are too great to do
incremental redisplay.  When it does that, it moves the cursor to column
0 and goes from there.  That's what happens here.

In general, the redisplay code really wants to know where it is on the
line -- if it thinks it is at column 0 but is not, redisplay errors will
eventually occur.  Things like your PROMPT_COMMAND output will be
overwritten when readline moves the cursor around to make sure it's where
readline thinks it is.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

*** ../bash-4.0/parse.y 2009-01-08 08:29:12.000000000 -0500
--- parse.y     2009-02-25 15:58:25.000000000 -0500
***************
*** 1616,1623 ****
    int *ret;
  
!   ret = (int *)xmalloc (3 * sizeof (int));
    ret[0] = last_read_token;
    ret[1] = token_before_that;
    ret[2] = two_tokens_ago;
    return ret;
  }
--- 1616,1624 ----
    int *ret;
  
!   ret = (int *)xmalloc (4 * sizeof (int));
    ret[0] = last_read_token;
    ret[1] = token_before_that;
    ret[2] = two_tokens_ago;
+   ret[3] = current_token;
    return ret;
  }
***************
*** 1632,1635 ****
--- 1633,1637 ----
    token_before_that = ts[1];
    two_tokens_ago = ts[2];
+   current_token = ts[3];
  }
  
***************
*** 2669,2672 ****
--- 2671,2675 ----
    word_desc_to_read = (WORD_DESC *)NULL;
  
+   current_token = '\n';               /* XXX */
    last_read_token = '\n';
    token_to_read = '\n';