From: Eric Sunshine <sunshine@xxxxxxxxxxxxxx> This is a reroll of [1] which improves check-non-portable-shell's detection of one-shot environment variable assignment with shell functions. The only difference from v2 is that the commit messages have been adjusted to use more accurate terminology[2]. In particular, they now say that the behavior of one-shot variable assignment with a shell-function is _unspecified_, not _undefined_. [1]: https://lore.kernel.org/git/20240726081522.28015-1-ericsunshine@xxxxxxxxxxx/ [2]: https://lore.kernel.org/git/xmqqplr0t2bo.fsf@gitster.g/ Eric Sunshine (5): t3430: drop unnecessary one-shot "VAR=val shell-func" invocation t4034: fix use of one-shot variable assignment with shell function check-non-portable-shell: loosen one-shot assignment error message check-non-portable-shell: suggest alternative for `VAR=val shell-func` check-non-portable-shell: improve `VAR=val shell-func` detection t/check-non-portable-shell.pl | 4 ++-- t/t3430-rebase-merges.sh | 3 +-- t/t4034-diff-words.sh | 2 +- 3 files changed, 4 insertions(+), 5 deletions(-) Range-diff against v2: 1: 0d3c0593c9 ! 1: 3bf12762a5 t3430: drop unnecessary one-shot "VAR=val shell-func" invocation @@ Commit message t3430: drop unnecessary one-shot "VAR=val shell-func" invocation The behavior of a one-shot environment variable assignment of the form - "VAR=val cmd" is undefined according to POSIX when "cmd" is a shell + "VAR=val cmd" is unspecified according to POSIX when "cmd" is a shell function. Indeed the behavior differs between shell implementations and - even different versions of the same shell. One such ill-defined behavior + even different versions of the same shell. One such problematic behavior is that, with some shells, the assignment will outlive the invocation of the function, thus may potentially impact subsequent commands in the test, as well as subsequent tests. A common way to work around the 2: 19ee8295ef ! 2: cb77c3dc66 t4034: fix use of one-shot variable assignment with shell function @@ Commit message t4034: fix use of one-shot variable assignment with shell function The behavior of a one-shot environment variable assignment of the form - "VAR=val cmd" is undefined according to POSIX when "cmd" is a shell + "VAR=val cmd" is unspecified according to POSIX when "cmd" is a shell function. Indeed the behavior differs between shell implementations and even different versions of the same shell, thus should be avoided. 3: 220ca26d4f ! 3: 0b3716cfb3 check-non-portable-shell: loosen one-shot assignment error message @@ Commit message potential problem with one-shot assignments and shell functions. Another problem is that some shells do not actually export the variable to commands which the function invokes[1]. More significantly, however, the - behavior of one-shot assignments with shell functions is considered - undefined by POSIX[2]. + behavior of one-shot assignments with shell functions is not specified + by POSIX[2]. Given this new understanding, the presented error message ("assignment extends beyond 'shell_func'") is too specific and potentially misleading. Address this by emitting a less specific error message. (Note that the wording "is not portable" is chosen over the more - specific "has undefined behavior according to POSIX" for consistency - with almost all other error message issued by this "lint" script.) + specific "behavior not specified by POSIX" for consistency with almost + all other error message issued by this "lint" script.) [1]: https://lore.kernel.org/git/xmqqbk2p9lwi.fsf_-_@gitster.g/ [2]: https://lore.kernel.org/git/xmqq34o19jj1.fsf@gitster.g/ 4: 4910756aab = 4: 24ae9be947 check-non-portable-shell: suggest alternative for `VAR=val shell-func` 5: 7a15553a5a ! 5: 38cd3556c5 check-non-portable-shell: improve `VAR=val shell-func` detection @@ Commit message check-non-portable-shell: improve `VAR=val shell-func` detection The behavior of a one-shot environment variable assignment of the form - "VAR=val cmd" is undefined according to POSIX when "cmd" is a shell + "VAR=val cmd" is unspecified according to POSIX when "cmd" is a shell function. Indeed the behavior differs between shell implementations and even different versions of the same shell, thus should be avoided. -- 2.45.2
