bug-libtool
[Top][All Lists]
Advanced

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

bug#40072: Incorrect escaping on MinGW 32-bit


From: Bob Friesenhahn
Subject: bug#40072: Incorrect escaping on MinGW 32-bit
Date: Sun, 15 Mar 2020 14:11:24 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Sun, 15 Mar 2020, Jeffrey Walton wrote:

On Sun, Mar 15, 2020 at 10:48 AM Jeffrey Walton <address@hidden> wrote:

On Sun, Mar 15, 2020 at 9:59 AM Bob Friesenhahn
<address@hidden> 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
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt





reply via email to

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