Re: Mangled argument vector choking on spaces?

[David A. Wheeler]

I wrote:
> > SBCL =/cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl"

On Tue, 30 Dec 2014 23:38:20 -0800, Paul Eggert <address@hidden> replied:
> That wouldn't work for commands that do stuff like this:
>     $(MAKE) SBCL="$(SBCL)"

Sure, but this minor variation WOULD work in a makefile, and it's an easy fix:
 $(MAKE) SBCL='$(SBCL)'

You can also embed double-quotes when setting environment variables and 
invoking make directly:
 ENV_SBCL='/cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl"' make 
demo3

Another possible option (noted below) is to use single quotes instead of double 
quotes.
Maybe that would be the "easiest way forward".


> There is no simple and clean solution to this problem, I'm afraid.

That may be true, but maybe we can find "simple and clean enough".
There are really only 3 main options that I see to disambiguate
"spaces used as argument separators" and "spaces in pathnames" in input:
1. backslash prefixing (but this is heavily overloaded because this data goes a 
varying number of unquoting processes),
2. double quotes
3. single quotes


> The best place to start fixing it would be with GNU Make...

But that only works with GNU make.  GNU make is great, but it's not the only 
make.
Autoconf (and automake) are supposed to work with other makes, so any
solution needs to *NOT* depend on GNU make.

> In the meantime, people will just have to live with not having
> white space in their development sources' directory names.

The problem is that that's not the problem :-).
I agree that developers should avoid having whitespace in their source dirnames;
typically this is easy to do.

The problem is that in many *USER* (builder) environments,
tools and configuration information have pathnames with spaces.
This is NOT the developer's environment at all, and thus the
developer CANNOT control this.  Users can't control it either, actually; it is
a current fact of their environment, especially if they use Mac OS X or Windows,
and not something they can change.
They can do workarounds with symlinks, etc., to try to *hide* the reality, but
since autoconf is supposed to do things *automatically*, that means that
autoconf fails to do the one job it's supposed to do: automatic configuration.

--- David A. Wheeler