Thank you for the review and comments. 2023年4月21日(金) 1:31 Junio C Hamano <gitster@xxxxxxxxx>: > The above sounded good before I looked at the patch, and it still is > good in theory, but it start to look mostly academic especially with > enclosing $# inside a pair of double-quotes, and the variable would > have only digits. The same for $i and $j that appear in the loop > control "for ((i=0, j=0; ...)); do". The story is pretty much the > same for local variables we set outselves to signal our findings, > like $pcmode that is only set to either 'yes' or 'no'. I need to admit that this report is not associated with a problem that has actually happened in real-world uses. In that sense, maybe you could regard these changes as more and less academic. To be fair, I think I first need to explain the background. We first received the change as a part of the commits for a consistent code style in our project, which contains copies of git-completion.bash and git-prompt.sh. Since these files came from the upstream Git project and are not something we are maintaining in our project, we rejected the changes to these two files. However, I still think it's worth forwarding the contributions from Edwin to the upstream, so I expanded the changes to similar cases in the same files and posted them here. > Is there a practical use case for an IFS that is set to split a run > of digits somewhere in between (e.g. "IFS=5")? Is there any > realistic setting of IFS that breaks the command line completion > without this patch, If you are talking about the ``default'' settings of IFS in an interactive session, I don't think there would be a practical use to set IFS to something other than <space><tab><newline>. However, the expected usage of IFS is to ``temporarily'' set a non-trivial value to IFS, run some commands referencing IFS (such as word splitting of unquoted variable expansions or the `read' builtin), and finally restore IFS to the original state. These three steps can be performed in three separate command lines in an interactive shell. The problem is that git prompt and completion settings can be invoked between these command lines, where IFS has the temporary value, regardless of whether the user intends so. > but the IFS is usable without breaking all other > things people wrote as shell scripts and you use everyday? First, an independent shell script will never be affected by IFS in interactive sessions because IFS is reset to <space><tab><newline> at the startup of the shell as requested by POSIX [XCU 2.5.3 IFS ¶3], so the only relevant scripts here are the settings of interactive shells. I assume you are not including random personal settings written by beginners (where we can easily find broken settings), and then there are not too many projects of widely used Bash interactive settings. Among such projects, recent projects are carefully written so that they won't be affected by random IFS. An old project, bash-completion, still contains the parts affected by random IFS, but the discussions for possible solutions are ongoing (e.g. in the following refs): https://github.com/scop/bash-completion/issues/723 https://github.com/scop/bash-completion/issues/720#issuecomment-1093764792 https://github.com/scop/bash-completion/pull/739 > If there is no such realistic setting of IFS, most, if not all, of > the changes presented here, while they may not be incorrect per-se, > look purely academic. > > It's not like this patch was produced by enclosing each and every > variable reference machanically inside a pair of double-quotes, > right? If there were variable references that ought to be split at > IFS whitespace, the patch would have left them alone. The readers > also need to assume the opposite for those variable references that > are touched by this patch while reviewing it. I think I miss the intent of this paragraph. I made this patch manually, i.e., edited each line of `test' and `[' by hand, but the procedure is actually mechanical. There can be use cases to split words by IFS for the other commands or shell constructs, but specifically for the `test' and `[' builtins, the words should never be split because it totally breaks the semantics that these builtins process. > Is there any change in this patch that do fix a real problem with > some more realistic IFS setting? No, this patch focuses on solely the problems of `test' and `[' caused by custom IFS, (though I'm not convinced that the problem caused by the custom IFS would be ``virtual''). > Setting IFS to a digit does not > count. If there is, then mixing such a real fix in many academic > changes is even worse, as the latter clutters the patch and makes it > harder to assess the former. It is like hiding a gem in a lot of > cobblestones. > > In other words, this patch looks way too noisy to be reviewed to > discover its real worth. > > Thanks. By the way, in the original patch, I tried to minimize the changes so just continued to use `test' and `[', but a solution that is generally considered preferable would be actually to switch to `[[ ... ]]'. If requested so, I can edit the patch.
