On 4/16/20 10:11 AM, Chet Ramey wrote: > 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.
As a programmer, I can understand that this may be a tough fix. However, as a user, I must say that I expect PROMPT_COMMAND to be run whenever PS1 is printed to prompt me for a new command. The bash man page makes this clear. To quote: PROMPT_COMMAND If set, the value is executed as a command prior to issuing each primary prompt. My PROMPT_COMMAND does a lot of neat stuff. It works flawlessly too, but obviously not after using, for example, <C-x><C-e>, because it doesn't get invoked then. This means that indicators about the most recent command are not updated when I open an editor to enter a command (or use histverify or show completions). A simple example where the prompt is not updated as expected (this one doesn't involve PROMPT_COMMAND, but shows why a full prompt update is desired): $ bash --norc $ PS1='[$?] '"$PS1" # now, exit status is in prompt, which is pretty useful # use <C-x><C-e> to edit and enter command "false" and save and quit # the exit status should be [1], but is [0], so the indicator is wrong I hope this clarifies my point of view on this issue. It may be a tough ask, so I don't expect a ton of effort to fix this if others aren't complaining. In any case, thanks so much for all of your magnificent work on Bash. I've been using Bash for years, and I don't plan to stop! I wish I had the knowledge of Bash internals to just code up a patch. I tried, but it was to no avail. :( Thanks! -- Jason Franklin
