Dear Mantas, On 07/10/14 18:18, Mantas Mikulėnas wrote:
There was a question in #git recently on why __git_ps1 from git-prompt.sh does not allow colors in "$PS1 mode". From what I see, commit 1bfc51ac8141 talks about the need for \[ and \] assignments in $PS1, and commit cf4cac4cfc13 says that PS1 mode turns off color support since \[ and \] won't work; as I understand it, this is because bash will output literal "\[" if __git_ps1 tries to echo it. Internally, \[ and \] are translated by bash into 0x01 and 0x02 before passing the final string to readline. So there *is* a way to achieve the same effect in "PS1 mode" – __git_ps1 just needs to echo \001 and \002 before & after the color codes, and readline will interpret them correctly when calculating the prompt width. For example, echo $'foo\001\e[1m\002bar'. Might be worth considering, even if $PS1 mode is inferior to $PROMPT_COMMAND mode for other reasons.
I would actually prefer the PS1='$(__git_ps)' like way, as it is more generic and intuitive when you know generic Bourne shell ways.
The reason to go for PROMPT_COMMAND was that it appears to be the only way to set the PS1 prompt and let bash keep track of the length of the prompt properly. This is needed to allow browsing the bash history with long(er than width of the terminal) command lines without the terminal getting messed up. And I'm still not sure PROMPT_COMMAND mode fixes this properly, but it passed the tests where command substitution mode failed.
IMHO the way colours are now implemented could very well be considered a workaround for a bug in bash. Only I'm not skilled enough (or have enough time) to get to the bottom of it...
I hope this answers your question. Cheers Simon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html