[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #41246] Allow to switch shell batch mode at runtime instead of

From: Paul Smith
Subject: Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time
Date: Tue, 04 Feb 2014 12:28:53 -0500

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...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]