bug-make
[Top][All Lists]
Advanced

[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: Mike Hommey
Subject: Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time
Date: Thu, 6 Feb 2014 18:54:33 +0900
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Feb 06, 2014 at 10:45:39AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 6 Feb 2014 16:01:06 +0900
> > From: Mike Hommey <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden
> > 
> > I gave multiple examples already. It doesn't require backslashes to be a
> > problem. Here's another one:
> > 
> > $ cat <<EOF >foo.mk
> > default:
> >         c:/path/to/python.exe -c 'import sys; sys.argv[1:]' "a" b c
> > EOF
> > $ make -f foo.mk
> > c:/path/to/python.exe -c 'import sys; sys.argv[1:]' "a" b c
> > ['a b', 'c']
> > 
> > And that (obviously) doesn't need make to fail:
> > (in a cmd.exe shell):
> > > c:/path/to/sh.exe -c "c:/path/to/python.exe -c 'import sys; sys.argv[1:]' 
> > > \"a\" b c"
> > ['a b', 'c']
> > 
> > (yes, this is how make quotes it, and the quoting is correct)
> 
> If you get the same result from the command line, then how is this a
> problem with what Make does?  What am I missing?

The point is, batch shell mode only flag is advertized in config.h as
being the workaround for the broken sh -c. I'd like that workaround to
be available at runtime instead of build time.

> > > > $ mkdir foo
> > > > $ echo foo > foo/bar
> > > > $ cat <<EOF >foo.mk
> > > > default:
> > > >         grep foo foo\\bar
> > > >         grep "foo" foo\\bar
> > > > $ make -f foo.mk
> > > > grep foo foo\\bar
> > > > foo
> > > > grep "foo" foo\\bar
> > > > /usr/bin/sh: foobar: No such file or directory
> > > 
> > > If you use forward slashes, do you see any problems in this case?
> > 
> > Obviously, no. But again, this is not a path problem:
> > 
> > $ cat <<EOF >foo.mk
> > default:
> >         echo foo foo\\bar
> >         echo "foo" foo\\bar
> > EOF
> > $ make -f foo.mk
> > echo foo foo\\bar
> > foo foo\bar
> > echo "foo" foo\\bar
> > foo foobar
> > 
> > $ msysmake -f foo.mk
> > echo foo foo\\bar
> > foo foo\bar
> > echo "foo" foo\\bar
> > foo foo\bar
> 
> That's what I said earlier: if you want Posix compatibility with
> backslash characters when your shell is MSYS Bash, you need to use the
> MSYS Make.  The native build of Make doesn't treat backslashes as
> merely escape characters, it also treats them as directory separators.
> Obviously, that heuristic fails in this case, but the native Make is
> not supposed to deal with such cases.

The native build of make doesn't end up treating backslashes equally
depending on whether the command line happens to be nice enough for it
to call CreateProcess directly or not. While it makes /some/ technical
sense that it is this way, it makes *no* sense from a user perspective.
Add to that the fact that both direct CreateProcess and batch shell mode
have the same behaviour while sh -c doesn't.

And now that i look at it, it *is* another sh -c bug. sigh.

I'd be all for detecting if the shell used is win32 native or not, but
at least, a user-runtime-togglable workaround for that would be better.
So we're back to square one. How about that first patch of mine?

Mike



reply via email to

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