[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bind -x keyseq:shell_func related misbehaviour

From: MSB
Subject: Re: bind -x keyseq:shell_func related misbehaviour
Date: Wed, 10 Apr 2002 21:08:06 +0200

On Tue, 9 Apr 2002 12:33:04 -0400 address@hidden (Chet Ramey)

> > Repeat-By:
> >         # 1st problem:
> >         PROMPT_COMMAND='PS1="`pwd`> "'
> >         func() { cd.. ; }
> >         bind -x '"\C-o":func'
> >         
> >         #Now press Ctrl-O. Bash gives a new prompt that shows the
> >     #directory unchanged. 
> >     #Press ENTER or Ctrl-C so that bash gives you a new prompt.
> >         #The new prompt shows that in fact the directory was changed.
> This is not a problem, just the result of some incorrect assumptions. 

I think the majority of users will share my assumptions regarding this. If
the implementation does not match user expectations, it is a bug,
regardless of whether the code is technically okay (i.e. no dangling

> PROMPT_COMMAND is executed before bash calls readline() with $PS1 as
> the argument.  The `bind -x' causes `func' to be executed within the
> context of that same call to readline().  Since readline() is only
> called once, the prompt does not change. 

Different example:

> func() { PS1="foo> "; echo foo; }
> bind -x '"\C-o":func'
> PS1="bar> "
bar>  #Now press Ctrl-O

The "echo foo" is obviously executed before the display of the 2nd "bar>"
prompt. This means that the PS1="foo>" is also executed before the
displaying of said prompt. Please tell me why a prompt that is displayed
after an assignment to PS1 is the same as the prompt displayed before the
assignment. Or rather, please tell me why you think this behaviour is
correct. "Correct" in the sense of either accepted standards or desirable
behaviour from the user's POV. IMNSHO, the current implementation limits
the usefulness of the feature and should be changed.

This sentence no verb.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]