Re: [PATCH v2 5/8] git-prompt: add some missing quotes
- From
avih <avihpit@yahoo.com>
- Date
- Aug 15, 2024, 19:53 UTC
- Message-ID
- <2093707499.4382922.1723751628640@mail.yahoo.com>
- In-Reply-To
- <xmqqv801sil5.fsf@gitster.g>
On Thursday, August 15, 2024 at 10:15:53 PM GMT+3, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> Fair enough. My "we would prefer to treat $? exactly the same way > as no" still stands. If the user did IFS=o, "no" would be broken. > >> As the commit message notes, this is unlikely to fix things in >> practice, but it will fix things with weird IFS values. > > > Yes, so I'd prefer to see us being consistent. If we quote "$?" to > protect ourselves from crazy folks who set insane values to $IFS, we > should quote "no" the same way, no?
OK, I see what you mean. But IFS-split doesn't happen on literal shell input (i.e. script source). It only happens on parts which get expanded with parameter or arithmetic expansion or command substitution. To quote from POSIX (2024):
After parameter expansion (2.6.2), command substitution (2.6.3), and arithmetic expansion (2.6.4), if the shell variable IFS (see 2.5.3 Shell Variables ) is set and its value is not empty, or if IFS is unset, the shell shall scan each field containing results of expansions and substitutions that did not occur in double-quotes for field splitting; zero, one or multiple fields can result.
So 'IFS=n; reply=no; echo no; local x=no' work regardless of IFS, because there's no expansion, and IFS is not involved.
But 'IFS=n; reply=no; echo $reply; local x=$reply' will be affected when unquoted $reply expands as argument to "echo" (or "local"), and then gets split by "n", so it would echo "o" (" o" because reasons). Fixed with quotes: IFS=n; reply=no; echo "$reply"; local x="$reply"
Both can even be adjacent: 'IFS=n reply=no; echo no $reply' would echo "no o" in all shells, because the literal `no' is unaffected, but the expanded $reply is affacted.
So $? is the same as $reply in this regards - it expands to some value, so IFS gets involved, so it needs quotes. But a literal `no' works the same regardless if quoted or not.
Worth noting in our context is that zsh doesn't do IFS word-split by default on parameter expansion like $x, but does split the output of command substitution $(cmd....), and code in git-prompt.sh is expected to work in zsh as well (like it always did).