On Tue, May 24, 2016 at 12:23 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > Having said all that, this illustrates the root cause of different > behaviours better, but it is harder to reason about than simply > changing the variable name used in this shell function. POSIX reads > a bit fuzzy to me around here: > > ... each command of a multi-command pipeline is in a subshell > environment; as an extension, however, any or all commands in a > pipeline may be executed in the current environment. All other > commands shall be executed in the current shell environment. > > That essentially says nothing useful; it does not guarantee that > each command on a pipeline runs in its own subshell environment, and > a portable script must be prepared to see some of them run in the > current shell environment. Writing portable shell scripts sometimes is quite a mess :-) > So let's do this instead: > > -- >8 -- > Subject: t4204: do not let $name variable clobbered > > test_patch_id_file_order shell function uses $name variable to hold > one filename, and calls another shell function calc_patch_id as a > downstream of one pipeline. The called function, however, also uses > the same $name variable. With a shell implementation that runs the > callee in the current shell environment, the caller's $name would > be clobbered by the callee's use of the same variable. > > This hasn't been an issue with dash and bash. ksh93 reveals the > breakage in the test script. Maybe add ksh88 too, just to be "feature" complete. > Fix it by using a distinct variable name in the callee. Agreed. > Reported-by: Armin Kunaschik <megabreit@xxxxxxxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> -- 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