Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

From: Simon Oosthoek <s.oosthoek@xs4all.nl>
Date: Oct 1, 2012, 20:56 UTC
Message-ID: <506A0366.6030009@xs4all.nl>
In-Reply-To: <7vr4piaryi.fsf@alter.siamese.dyndns.org>

On 01/10/12 21:54, Junio C Hamano wrote:

Show 26 quoted lines

> Now you lost me.  The documentation of PROMPT_COMMAND in "man bash"
> says this:
> 
>        PROMPT_COMMAND
>               If set, the value is executed as a command prior to
>               issuing each primary prompt.
> 
> So yes, if you say "PROMPT_COMMAND='whatever'", you will get output
> from 'whatever' followed by what $PS1 would normally give you.  
> If you do not want to see PS1 after 'whatever' gives you, you have
> to set it to an empty string.
> 
> On the other hand, they way people have been using __git_ps1 is (as
> described in the prompt script) to do something like this:
> 
> 	PS1='...cruft... $(__git_ps1 "%s") ...cruft...'
> 
> To keep supporting them, __git_ps1 has to be a function that writes
> the prompt string to its standard output.  The external interface of
> PROMPT_COMMAND also is that it wants a command that emits the string
> desired for the prompt to its standard output.  I do not see any
> "when it is used like this, X, but when it is used like that, Y"
> kind of issue around it, either.
> 
> So what is the problem????
>

Well, I hadn't thought about that way of using it. It works in a way...

But PS1 is set and interpreted in a special way by bash (I gather from examples, I'm kind of confused by it).

It's possible to set PS1 to nothing and print a string from PROMPT_COMMAND, but then you miss out on all the features of the PS1 interpretation by bash and compared to the use of __git_ps1 at the moment, it has to put out quite a different string. Because if you like to see user@host+workdir (git-status)[$#] the current users of __git_ps1 say PS1="\u@host+\w $(__git_ps1 "%s")\$ ", but all __git+ps1 has to put out is "(branch)" or "(branch *)", etc.

If it has to print the same prompt in PC mode, it has to add all the user/host/workdir/[$#] data as well, withouth being able to use the bash internal interpretation (because that is only working when PS1 is set).

The example(s) I found when googling for a solution were to set PS1 inside the PC function, in a way that it was possible to add color encodings, without messing up the wrapping. This is _impossible_ using command substitution, because then bash doesn't interpret the \[ and \] around the color codes, and that messes up the accounting of how long the prompt string is.

/Simon