Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths)

[Frank Heckenbach]

Eli Zaretskii wrote:

> > Actually, in all the examples above, there would be no change in
> > behaviour at all.
> 
> With Posix shells, I hope so.

Strictly speaking, there's no change in behaviour (in those cases)
either. If you write

  FOO = foo\ bar
  $(FOO): ; @echo '$(FOO)'

Make will call the shell with "echo 'foo\ bar'", whether or not this
makes sense to any given shell. But it's exactly the same as it does
now, that's what I was saying.

> We will need to think about other shells, like Python, Perl and
> whatnot (let alone Windows shells -- but let's forget about
> Windows for the moment).

Actually that's what I was trying to get at with my rsync example.
If you have let's say "dir c:\foo\ c:\bar\" on a Windows
command-line, I assume it works now (\ is not special), and it will
continue to work (as I said, no change in behaviour in such cases),
though slightly oddly because make thinks it's a single word, and
the Windows shell sees it as two words. It works because make's
interpretation doesn't matter if it only passes it through. It will
matter when used e.g. in a dependency list:

DIRS = c:\foo\ c:\bar\

foo: $(DIRS); @dir $(DIRS) > $@

Currently, this probably works as intended. With our proposed
change, the command-line would remain the same, but the dependency
would now be on a single directory with the (probably invalid) name
"c:\foo\ c:\bar\". So here we have a backward-incompatibility.
Question, is this relevant? Do people often use lists of (files and)
directories, with trailing backslashes? I think/hope not.