On Wed, Sep 26, 2018 at 12:16:16PM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > I quote >"$file" (but not var=$var) because the CodingGuidelines > > tells me to: > > > > - Redirection operators should be written with space before, but no > > space after them. In other words, write 'echo test >"$file"' > > instead of 'echo test> $file' or 'echo test > $file'. Note that > > even though it is not required by POSIX to double-quote the > > redirection target in a variable (as shown above), our code does so > > because some versions of bash issue a warning without the quotes. > > > > ;-) Oh, indeed, I didn't notice that. > Subject: t7005: make sure it passes under /bin/bash > > In POSIX.1 compliant shells, you should be able to use a variable > reference without quoting for the target of the redirection, e.g. > > echo foo >$file > echo bar >$1 > > without fear of substitution of $file getting split at $IFS. > However, some versions of bash throws a warning, especially when I would say it's an error, not a warning. Regarding the "some versions", it's unclear when Bash started to apply word splitting to the filename in redirection. The changelog of version 2.04-beta2 contains the following entry: When running in POSIX.2 mode, bash no longer performs word splitting on the expanded value of the word supplied as the filename argument to redirection operators. so it must have started earlier, but I found further no sign of it in the changelog. In its man page the first ever mention of word splitting affecting redirections came only later, in version 2.04. v2.04 was release in 2000, so it's bordering on "since forever". > they are invoked as /bin/bash (not as /bin/sh). Those who build > with SHELL_PATH=/bin/bash and run t/t7005-editor.sh triggers an The grammar here confused me a bit... maybe s/triggers/trigger/ ? > unnecessary failure due to this issue. > > Fix it by making sure that the generated "editor" script quotes the > target of redirection. > > While at it, update the way to creatd these scripts to use the > write_script wrapper, so that we do not have to worry about writing > the she-bang line and making the result executable. > > Reported-by: Alexander Pyhalov <apyhalov@xxxxxxxxx> > Suggested-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > t/t7005-editor.sh | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh > index b2ca77b338..b0c4cc4ca0 100755 > --- a/t/t7005-editor.sh > +++ b/t/t7005-editor.sh > @@ -20,11 +20,9 @@ fi > > for i in GIT_EDITOR core_editor EDITOR VISUAL $vi > do > - cat >e-$i.sh <<-EOF > - #!$SHELL_PATH > + write_script "e-$i.sh" <<-EOF This can't be <<-\EOF ... > echo "Edited by $i" >"\$1" ... because here we have to expand $i, and, therefore, we need both double-quotes and \-escaping for $1. Ok. > EOF > - chmod +x e-$i.sh > done > > if ! test -z "$vi" > @@ -112,8 +110,9 @@ do > done > > test_expect_success 'editor with a space' ' > - echo "echo space >\$1" >"e space.sh" && > - chmod a+x "e space.sh" && > + write_script "e space.sh" <<-\EOF && But here it can be <<-\EOF ... > + echo space >"$1" ... so here we don't need the \-escaping. Good. > + EOF > GIT_EDITOR="./e\ space.sh" git commit --amend && > test space = "$(git show -s --pretty=format:%s)" >
