On 01/10/12 21:54, Junio C Hamano wrote:
> Now you lost me.  The documentation of PROMPT_COMMAND in "man bash"
> says this:
>               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.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to