Subject: Re: t7005-editor.sh failure

From: SZEDER Gábor <[email-masked]>
Date: Thu, 27 Sep 2018 22:53:37 +0200

On Wed, Sep 26, 2018 at 12:16:16PM -0700, Junio C Hamano wrote:
> Junio C Hamano <[email-masked]> 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 <[email-masked]>
> Suggested-by: SZEDER Gábor <[email-masked]>
> Signed-off-by: Junio C Hamano <[email-masked]>
> ---
>  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)"
>