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: Tue, 4 Feb 2014 13:34:31 +0900
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Feb 01, 2014 at 11:29:19AM +0200, Eli Zaretskii wrote:
> > From: Paul Smith <address@hidden>
> > Cc: Mike Hommey <address@hidden>, address@hidden, 
> >     address@hidden, address@hidden
> > Date: Fri, 31 Jan 2014 10:59:13 -0500
> > 
> > My question, or _challenge_ if you like, is whether we can find a way to
> > know, without any hints from the user, whether a given command line will
> > work properly for /bin/sh -c in Windows, or if it needs to use a batch
> > file.
> 
> Mike, could you please post some details about your use case(s) that
> required this?  I'm not sure why would quotes not work with a Unixy
> shell.
> 
> Perhaps this is once again something specific to the MSYS conversion
> of file names?

I'm not sure why it happens, but here's how it manifests:

$ cat <<EOF > foo.mk
foo:
        $(LS) "c:\\Program Files"
EOF
$ make -f foo.mk LS=$(which ls)
C:/mozilla-build/msys/bin/ls.exe "c:\\Program Files"
C:/mozilla-build/msys/bin/ls.exe: c:\Program: No such file or directory
C:/mozilla-build/msys/bin/ls.exe: Files: No such file or directory
foo.mk:2: recipe for target 'foo' failed
make: *** [foo] Error 2

This happens for various absolute-path versions of LS, but not when
LS=ls. This is something I mentioned in bug 40241 comment 12 and 13.

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)

When < is not there and make executes grep directly, it fails with:
  grep: foo\bar: No such file or directory

So there is a lack of consistency in how backslashes are treated when
make uses sh -c or not.

Note the second patch to bug 41246 solves the first issue but not the
second. The first patch, with .BATCH_MODE_SHELL added to the makefile
"fixes" both issues.

Mike



reply via email to

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