| Message ID | 20240401113033.28709-1-ville.skytta@iki.fi (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 758b4e137349b8548ada07346ab82e82079b43a3 |
| Headers | show |
| Series | completion: fix prompt with unset SHOWCONFLICTSTATE in nounset mode | expand |
Ville Skyttä <ville.skytta@iki.fi> writes: > `GIT_PS1_SHOWCONFLICTSTATE` is a user variable that might not be set, > causing errors when the shell is in `nounset` mode. > > Take into account on access by falling back to an empty string. > > Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> > --- Obviously a good thing to do. A related tangent is that $ git grep -e '$GIT_PS1' -e '${GIT_PS1_[A-Z0-9_]*}' contrib/completion/ shows a hit for the line with SHOWCONFLICTSTATE, plus two lines with GIT_PS1_SHOWUPSTREAM that lack the "if unset then use this value". Do you want to do another patch to fix them, or are they good as-is for some reason? Thanks. > contrib/completion/git-prompt.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh > index 71f179cba3..3826f52dec 100644 > --- a/contrib/completion/git-prompt.sh > +++ b/contrib/completion/git-prompt.sh > @@ -528,7 +528,7 @@ __git_ps1 () > fi > > local conflict="" # state indicator for unresolved conflicts > - if [[ "${GIT_PS1_SHOWCONFLICTSTATE}" == "yes" ]] && > + if [[ "${GIT_PS1_SHOWCONFLICTSTATE-}" == "yes" ]] && > [[ $(git ls-files --unmerged 2>/dev/null) ]]; then > conflict="|CONFLICT" > fi
On Mon, 1 Apr 2024 at 15:31, Junio C Hamano <gitster@pobox.com> wrote: > > Ville Skyttä <ville.skytta@iki.fi> writes: > > > `GIT_PS1_SHOWCONFLICTSTATE` is a user variable that might not be set, > > causing errors when the shell is in `nounset` mode. > > > > Take into account on access by falling back to an empty string. > > > > Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> > > --- > > Obviously a good thing to do. > > A related tangent is that > > $ git grep -e '$GIT_PS1' -e '${GIT_PS1_[A-Z0-9_]*}' contrib/completion/ > > shows a hit for the line with SHOWCONFLICTSTATE, plus two lines with > GIT_PS1_SHOWUPSTREAM that lack the "if unset then use this value". > Do you want to do another patch to fix them, or are they good as-is > for some reason? I initially actually changed those very lines too when working on the fix for the issue I faced with GIT_PS1_SHOWCONFLICTSTATE. However, both occurrences are within __git_ps1_show_upstream, and the only call site for that function is protected by a check on the variable that does take possible unset state into account; the function will in the file's current form never be called with it unset. Additionally, the first occurrence is immediately following a line that sets the variable, so that one is "doubly protected". Therefore, I decided to undo those changes and not include them here. I guess it's a matter of taste whether one finds it desirable to protect those accesses nevertheless, but it's not strictly necessary. Ville
Ville Skyttä <ville.skytta@iki.fi> writes: > I initially actually changed those very lines too when working on the > fix for the issue I faced with GIT_PS1_SHOWCONFLICTSTATE. However, > both occurrences are within __git_ps1_show_upstream, and the only call > site for that function is protected by a check on the variable that > does take possible unset state into account; the function will in the > file's current form never be called with it unset. Additionally, the > first occurrence is immediately following a line that sets the > variable, so that one is "doubly protected". > > Therefore, I decided to undo those changes and not include them here. > I guess it's a matter of taste whether one finds it desirable to > protect those accesses nevertheless, but it's not strictly necessary. I am glad you took a look into it already. I wonder if we can somehow keep this "institutional knowledge" to help the next person by saving them from wasting time wondering about the reason why it is safe (iow, what you have found out and described above). Perhaps a patch like this? I dunno. Anyway, thanks again for digging! contrib/completion/git-prompt.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git i/contrib/completion/git-prompt.sh w/contrib/completion/git-prompt.sh index 3826f52dec..b05e4cb049 100644 --- i/contrib/completion/git-prompt.sh +++ w/contrib/completion/git-prompt.sh @@ -113,6 +113,10 @@ printf -v __git_printf_supports_v -- '%s' yes >/dev/null 2>&1 # stores the divergence from upstream in $p # used by GIT_PS1_SHOWUPSTREAM +# +# Note: ${GIT_PS1_SHOWUPSTREAM} is used without the nounset +# protection ${GIT_PS1_SHOWUPSTREAM-}, as the only caller calls +# only after making sure it is already set. __git_ps1_show_upstream () { local key value
On Mon, 1 Apr 2024 at 17:26, Junio C Hamano <gitster@pobox.com> wrote: > > Ville Skyttä <ville.skytta@iki.fi> writes: > > > I initially actually changed those very lines too when working on the > > fix for the issue I faced with GIT_PS1_SHOWCONFLICTSTATE. However, > > both occurrences are within __git_ps1_show_upstream, and the only call > > site for that function is protected by a check on the variable that > > does take possible unset state into account; the function will in the > > file's current form never be called with it unset. Additionally, the > > first occurrence is immediately following a line that sets the > > variable, so that one is "doubly protected". > > > > Therefore, I decided to undo those changes and not include them here. > > I guess it's a matter of taste whether one finds it desirable to > > protect those accesses nevertheless, but it's not strictly necessary. > > I am glad you took a look into it already. I wonder if we can > somehow keep this "institutional knowledge" to help the next person > by saving them from wasting time wondering about the reason why it > is safe (iow, what you have found out and described above). Perhaps > a patch like this? I dunno. TBH, I'd personally just rather patch the "vulnerable" reference to guard against this. Sent that approach in another mail with subject "[PATCH] completion: protect prompt against unset SHOWUPSTREAM in nounset mode".
Ville Skyttä <ville.skytta@iki.fi> writes: > TBH, I'd personally just rather patch the "vulnerable" reference to > guard against this. Sent that approach in another mail with subject > "[PATCH] completion: protect prompt against unset SHOWUPSTREAM in > nounset mode". Yup, that would be more future-proof. Will queue. Thanks.
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index 71f179cba3..3826f52dec 100644 --- a/contrib/completion/git-prompt.sh +++ b/contrib/completion/git-prompt.sh @@ -528,7 +528,7 @@ __git_ps1 () fi local conflict="" # state indicator for unresolved conflicts - if [[ "${GIT_PS1_SHOWCONFLICTSTATE}" == "yes" ]] && + if [[ "${GIT_PS1_SHOWCONFLICTSTATE-}" == "yes" ]] && [[ $(git ls-files --unmerged 2>/dev/null) ]]; then conflict="|CONFLICT" fi
`GIT_PS1_SHOWCONFLICTSTATE` is a user variable that might not be set, causing errors when the shell is in `nounset` mode. Take into account on access by falling back to an empty string. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> --- contrib/completion/git-prompt.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)