On Wed, Sep 26, 2018 at 5:53 AM Martin Ågren <martin.ag...@gmail.com> wrote:
> I came up with the following commit message. What do you think about it?
>
> t7005-editor: quote filename to fix whitespace-issue
>
> Commit 4362da078e (t7005-editor: get rid of the SPACES_IN_FILENAMES
> prereq, 2018-05-14) removed code for detecting whether spaces in
> filenames work. Since we rely on spaces throughout the test suite
> ("trash directory.t1234-foo"), testing whether we can use the filename
> "e space.sh" was redundant and unnecessary.
>
> In simplifying the code, though, the commit introduced a regression around
> how spaces are handled, not in the /name/ of the script, but /in/ the
> script itself. The editor-script created looks like this:
>
> echo space >$1
>
> We will try to execute something like
>
> echo space >/foo/t/trash directory.t7005-editor/.git/COMMIT_EDITMSG
>
> Most shells seem to be able to figure out that the filename doesn't end
> with "trash" but continues all the way to "COMMIT_EDITMSG", but at least
> one shell chokes on this.
>
> Make sure that the editor-script quotes "$1".
This description of the behavior is misleading (actually, actively
wrong). Shells are not somehow inferring that the space is part of the
redirect filename. The missing piece is that the following all behave
the same:
echo foo bar >cow
echo >cow foo bar
echo foo >cow bar
That is, they all create a file named "cow" with content "foo bar".
So, in your example:
echo space >/foo/t/trash directory.t7005-editor/.git/COMMIT_EDITMSG
what is actually happening is that it is creating a file named
"/foo/t/trash" with content "space
directory.t7005-editor/.git/COMMIT_EDITMSG".
As for the "ambiguous redirect" diagnostic, that seems to be Bash
trying to be helpful in reporting what is likely a programming error
(that is, forgetting to double-quote the expansion).
