On Tue, 2014-02-04 at 18:54 +0200, Eli Zaretskii wrote: > > Another issue is with backslashes in paths. > > > > For example: > > $ cat <<EOF > foo.mk > > foo: > > grep foo < foo\\bar > > EOF > > > > (Note the < is just there to trigger sh -c) > > > > This executes sh -c "grep foo < foo\\bar", which fails with: > > /usr/bin/sh: foobar: No such file or directory > > But in batch mode shell, this executes sh makennnnn.sh with a > content of > > grep foo < foo\\bar > > and that fails with: > > makennnnn.sh: line 1: foo\bar: No such file or directory > > > > (Note how in one case the backslash is eaten and not in the other > case) > > Why are you using backslashes in file names when your shell is a Unixy > shell? That makes little sense to me, and I don't see why Make on > Windows should support such use. Unixy shells are supposed to get > Unixy file names with forward slashes, including in redirection.
I agree about using backslashes as directory separators, that obviously cannot work in /bin/sh, even on Windows. But I do see a problem above; what if the literal file 'foo\bar' (a file with a backslash in the name) existed? Then this would work on UNIX but fail on Windows, because (Mike shows) too many backslashes are eaten. On UNIX, "grep foo < foo\\bar" would do as Mike shows the batch mode shell to do, and look for the literal file 'foo\bar', but note his example above where BOTH backslashes are dropped in non-batch mode. That seems wrong to me... _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make