GNU bug report logs - #40072
Incorrect escaping on MinGW 32-bit

Previous Next

To reply to this bug, email your comments to 40072 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeffrey Walton <noloader <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 07:40:56 -0400

Hi Everyone,

I'm working on a MSYS2 system on a Windows 7 host. MSYS2 can be
obtained at https://www.msys2.org/. I'm using the environment from
msys2-i686-20190524.exe. After installing MSYS2, click the MinGW
32-bit link on the desktop.

After configuring Expat (https://github.com/libexpat/libexpat), make
is resulting in:

libtool: link: gcc -g -O2 -Wall -Wextra -fexceptions -fno-strict-aliasing -Wmiss
ing-prototypes -Wstrict-prototypes -pedantic -Wduplicated-cond -Wduplicated-bran
ches -Wlogical-op -Wrestrict -Wnull-dereference -Wjump-misses-init -Wdouble-prom
otion -Wshadow -Wformat=2 -Wmisleading-indentation -fvisibility=hidden -DXML_ENA
BLE_VISIBILITY=1 -fno-strict-aliasing -o .libs/xmlwf.exe xmlwf-xmlwf.o xmlwf-xml
file.o xmlwf-codepage.o xmlwf-unixfilemap.o  ../lib/.libs/libexpat.dll.a -L/ming
w32/lib
./.libs/lt-xmlwf.c:164:35: error: expected ',' or ';' before 'C'
  164 | const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey Walton\\libe
xpat\\expat\\lib\\.libs";";
      |                                   ^
./.libs/lt-xmlwf.c:164:37: error: stray '\' in program
  164 | const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey Walton\\libe
xpat\\expat\\lib\\.libs";";
      |                                     ^
...

$ cat -n xmlwf/.libs/lt-xmlwf.c
     1
     2  /* ./.libs/lt-xmlwf.c - temporary wrapper executable for .libs/xmlwf.exe
     3     Generated by libtool (GNU libtool) 2.4.6
     4
   ...
   162  externally_visible const char * MAGIC_EXE = "%%%MAGIC EXE variable%%%";
   163  const char * LIB_PATH_VARNAME = "PATH";
   164  const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey Walton\\libe
xpat\\expat\\lib\\.libs";";
   165  const char * EXE_PATH_VARNAME = "PATH";
   166  const char * EXE_PATH_VALUE   = "\\home\\Jeffrey:Walton\\libexpat\\expat
\\lib\\.libs:\\mingw32\\lib:\\mingw32\\bin;";

And finally,

    $ libtool --version
    libtool (GNU libtool) 2.4.6

    $ autoconf --version
    autoconf (GNU Autoconf) 2.69

    $ automake --version
    automake (GNU automake) 1.16.1

Jeff

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Jeffrey Walton <noloader <at> gmail.com>
Cc: 40072 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#40072: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 08:59:34 -0500 (CDT)

On Sun, 15 Mar 2020, Jeffrey Walton wrote:

> Hi Everyone,
>
> I'm working on a MSYS2 system on a Windows 7 host. MSYS2 can be
> obtained at https://www.msys2.org/. I'm using the environment from
> msys2-i686-20190524.exe. After installing MSYS2, click the MinGW
> 32-bit link on the desktop.
>
> After configuring Expat (https://github.com/libexpat/libexpat), make
> is resulting in:
>
> libtool: link: gcc -g -O2 -Wall -Wextra -fexceptions -fno-strict-aliasing -Wmiss
> ing-prototypes -Wstrict-prototypes -pedantic -Wduplicated-cond -Wduplicated-bran
> ches -Wlogical-op -Wrestrict -Wnull-dereference -Wjump-misses-init -Wdouble-prom
> otion -Wshadow -Wformat=2 -Wmisleading-indentation -fvisibility=hidden -DXML_ENA
> BLE_VISIBILITY=1 -fno-strict-aliasing -o .libs/xmlwf.exe xmlwf-xmlwf.o xmlwf-xml
> file.o xmlwf-codepage.o xmlwf-unixfilemap.o  ../lib/.libs/libexpat.dll.a -L/ming
> w32/lib
> ./.libs/lt-xmlwf.c:164:35: error: expected ',' or ';' before 'C'
>  164 | const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey Walton\\libe
> xpat\\expat\\lib\\.libs";";

In my experience, Autotools has never supported paths which include 
spaces.  This is just too hard to fix given that the shell splits 
arguments on white-space by default.  Even if Autoconf, Automake, and 
Libtool where to somehow fix this problem for a well-crafted package, 
it would almost certainly fail once the configure script uses any 
shell content other than the provided macros.

There was already a challenge to solve given that backslash has 
special meaning to the shell.

For my purposes I made sure that my default Windows login directory 
does not include spaces in the path, but I also created a new 
directory path for builds which does not include spaces in the path 
and has Windows Defender scaning and automatic indexing disabled.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeffrey Walton <noloader <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 40072 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#40072: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 10:48:44 -0400

On Sun, Mar 15, 2020 at 9:59 AM Bob Friesenhahn
<bfriesen <at> simple.dallas.tx.us> wrote:
>
> On Sun, 15 Mar 2020, Jeffrey Walton wrote:
>
> > Hi Everyone,
> >
> > I'm working on a MSYS2 system on a Windows 7 host. MSYS2 can be
> > obtained at https://www.msys2.org/. I'm using the environment from
> > msys2-i686-20190524.exe. After installing MSYS2, click the MinGW
> > 32-bit link on the desktop.
> >
> > After configuring Expat (https://github.com/libexpat/libexpat), make
> > is resulting in:
> >
> > libtool: link: gcc -g -O2 -Wall -Wextra -fexceptions -fno-strict-aliasing -Wmiss
> > ing-prototypes -Wstrict-prototypes -pedantic -Wduplicated-cond -Wduplicated-bran
> > ches -Wlogical-op -Wrestrict -Wnull-dereference -Wjump-misses-init -Wdouble-prom
> > otion -Wshadow -Wformat=2 -Wmisleading-indentation -fvisibility=hidden -DXML_ENA
> > BLE_VISIBILITY=1 -fno-strict-aliasing -o .libs/xmlwf.exe xmlwf-xmlwf.o xmlwf-xml
> > file.o xmlwf-codepage.o xmlwf-unixfilemap.o  ../lib/.libs/libexpat.dll.a -L/ming
> > w32/lib
> > ./.libs/lt-xmlwf.c:164:35: error: expected ',' or ';' before 'C'
> >  164 | const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey Walton\\libe
> > xpat\\expat\\lib\\.libs";";
>
> In my experience, Autotools has never supported paths which include
> spaces.  This is just too hard to fix given that the shell splits
> arguments on white-space by default.  Even if Autoconf, Automake, and
> Libtool where to somehow fix this problem for a well-crafted package,
> it would almost certainly fail once the configure script uses any
> shell content other than the provided macros.
>
> There was already a challenge to solve given that backslash has
> special meaning to the shell.
>
> For my purposes I made sure that my default Windows login directory
> does not include spaces in the path, but I also created a new
> directory path for builds which does not include spaces in the path
> and has Windows Defender scaning and automatic indexing disabled.

Thanks Bob.

It seems (to me) Libtool is very close to the correct answer.

Taking a page from my experience trying to use the date(1) command
everywhere, I stopped using it. I now supply a small C program that
adds, subtracts, formats and prints dates. I call it from my scripts.
My scripts now work everywhere from AIX, BSDs, OS X, Solaris and
Windows. No putzing around anymore with different OS personalities.

Maybe libtool can do the same. Supply a small C program, compile it
and call it from the libtool scripts. Its would be quite easy to
supply the path in argv[1], and get back either (1) the original name
(no spaces), (2) a short file name or (3) a quoted long file name. If
the path gets split and shows up in pieces across argv[1]...argv[n-1],
then just combine the pieces because you know what is supposed to
happen.

Jeff

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeffrey Walton <noloader <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 40072 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#40072: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 15:00:52 -0400

[Message part 1 (text/plain, inline)]

On Sun, Mar 15, 2020 at 10:48 AM Jeffrey Walton <noloader <at> gmail.com> wrote:
>
> On Sun, Mar 15, 2020 at 9:59 AM Bob Friesenhahn
> <bfriesen <at> simple.dallas.tx.us> wrote:
> >
> > On Sun, 15 Mar 2020, Jeffrey Walton wrote:
> > ...
> Maybe libtool can do the same. Supply a small C program, compile it
> and call it from the libtool scripts. Its would be quite easy to
> supply the path in argv[1], and get back either (1) the original name
> (no spaces), (2) a short file name or (3) a quoted long file name. If
> the path gets split and shows up in pieces across argv[1]...argv[n-1],
> then just combine the pieces because you know what is supposed to
> happen.

Bob, see what you think about a program like the one attached. The C
code will be messier, but it is the same concept.

Here's what it returns during testing. The -c options means returns
string to use as a C declare.

With USE_WINDOWS_API (tested under MSYS):

    $ ./quote_path.exe "C:\Users\Jeffrey" "Walton\Desktop"
    C:\Users\JEFFRE~1\Desktop

    $ ./quote_path.exe -c "C:\Users\Jeffrey" "Walton\Desktop"
    "C:\\Users\\JEFFRE~1\\Desktop";

    $ ./quote_path.exe -c C:\\Users
    C:\\Users

Without USE_WINDOWS_API (tested under MSYS):

    $ ./quote_path.exe "C:\Users\Jeffrey" "Walton\Desktop"
    "C:\Users\Jeffrey Walton\Desktop"

    $ ./quote_path.exe -c "C:\Users\Jeffrey" "Walton\Desktop"
    "\"C:\\Users\\Jeffrey Walton\\Desktop\"";

    $ ./quote_path.exe C:\\Users\\Jeffrey Walton\\Desktop
    "C:\Users\Jeffrey Walton\Desktop"

    $ ./quote_path.exe -c C:\\Users\\Jeffrey Walton\\Desktop
    "\"C:\\Users\\Jeffrey Walton\\Desktop\"";

    $ ./quote_path.exe -c C:\\Users
    C:\\Users

I think offloading to an external program written for the specific
problem will probably simplify libtool and its helpers. It will make
your life a lot easier.

Jeff

[quote_path.cpp (text/x-c++src, attachment)]

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Jeffrey Walton <noloader <at> gmail.com>
Cc: 40072 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#40072: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 14:11:24 -0500 (CDT)

On Sun, 15 Mar 2020, Jeffrey Walton wrote:

> On Sun, Mar 15, 2020 at 10:48 AM Jeffrey Walton <noloader <at> gmail.com> wrote:
>>
>> On Sun, Mar 15, 2020 at 9:59 AM Bob Friesenhahn
>> <bfriesen <at> simple.dallas.tx.us> wrote:
>>>
>>> On Sun, 15 Mar 2020, Jeffrey Walton wrote:
>>> ...
>> Maybe libtool can do the same. Supply a small C program, compile it
>> and call it from the libtool scripts. Its would be quite easy to
>> supply the path in argv[1], and get back either (1) the original name
>> (no spaces), (2) a short file name or (3) a quoted long file name. If
>> the path gets split and shows up in pieces across argv[1]...argv[n-1],
>> then just combine the pieces because you know what is supposed to
>> happen.
>
> Bob, see what you think about a program like the one attached. The C
> code will be messier, but it is the same concept.

This seems like a good idea but it does not address the problem that 
Autoconf and Automake can not currently support paths with spaces in 
them.

If a path is encoded so that it does not appear to contain a space, 
then it is wise to remember that paths are saved in various places and 
used in various ways.  Some of these paths may be baked into the 
library or program.

Microsoft Windows does provide an API in order to obtain an 
obfusticated short name or convert it to the normal path.  This was 
needed in order for Windows 95 (and earlier) programs to be able to 
handle long file names.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.