Re: [bug] PROMPT_COMMAND is not executed as expected in some situations

From	Chet Ramey <chet.ramey@case.edu>
Newsgroups	gnu.bash.bug
Subject	Re: [bug] PROMPT_COMMAND is not executed as expected in some situations
Date	2020-04-16 10:11 -0400
Organization	ITS, Case Western Reserve University
Message-ID	<mailman.405.1587046312.3066.bug-bash@gnu.org> (permalink)
References	<00547d35-6a4e-bc3d-3845-e1fbf23a6469@quoininc.com> <8b3df1f1-de20-29e4-676b-7b8e8162ef8e@case.edu> <6aea7be4-449f-bce2-ec06-01f5ee2aecd2@quoininc.com> <6892a004-2e6d-9a55-ec08-1ff5af4f8bd2@case.edu>

Show all headers | View raw

On 4/16/20 9:21 AM, Franklin, Jason wrote:
> On 4/15/20 5:35 PM, Chet Ramey wrote:
>> These all pretty much all fall into the category of the editor reprinting
>> the prompt before it returns.
> 
> Hmmm...
> 
> So, is there no way to have Bash handle the printing of the prompt after
> the return of the command and of the editor?

Bash doesn't have control at that point. It's readline running a bindable
function. It's as if you hit ^L when the readline line buffer was empty:
readline reprints the prompt, but should it call back to bash somehow --
through a hook function that doesn't currently exist -- to execute
PROMPT_COMMAND?

> This would allow PROMPT_COMMAND to function as expected.  It is
> surprising to see status indicators in my prompt NOT be updated when
> using <C-x><C-e>.

I don't think that most people expect PROMPT_COMMAND in that situation.
> I thought that this would be easy.  Is it really not possible to fix?

I'm saying it's not a bug at all, and doesn't need fixing.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: [bug] PROMPT_COMMAND is not executed as expected in some situations Chet Ramey <chet.ramey@case.edu> - 2020-04-16 10:11 -0400

csiph-web