[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
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Eli Zaretskii, 2014/02/01
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time,
Mike Hommey <=
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Eli Zaretskii, 2014/02/04
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Mike Hommey, 2014/02/05
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Eli Zaretskii, 2014/02/05
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Mike Hommey, 2014/02/05
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Eli Zaretskii, 2014/02/05
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Mike Hommey, 2014/02/05
- Re: [bug #41246] Allow to switch shell batch mode at runtime instead of build time, Mike Hommey, 2014/02/05