Re: Mangled argument vector choking on spaces?

[David A. Wheeler]

On Mon, 29 Dec 2014 16:27:51 -0800, Kip Warner said:
> My configure.ac updates CXXFLAGS periodically during execution, such as
> via pkg-config. Some of the include paths returned from pkg-config's
> --cflags contain spaces which I require.
...

Bob Friesenhahn said:
> The solution is to assure that all paths used do not include spaces.

Kip Warner said:
> Unfortunately I need spaces on GNU systems and possibly elsewhere.

I think "don't have spaces in paths" is increasingly impractical advice.
Mac OS X and Windows systems (msys, cygwin) *normally* have
directory names with spaces, and these names *are* the correct probe results.

Autoconf is intended to be "a tool for producing shell scripts that 
automatically
configure software source code packages to adapt to many kinds of Posix-like 
systems...
The configuration scripts produced by Autoconf require no manual user 
intervention when run".
But this is *NOT* true for the large number of systems where spaces occur in 
directory names,
and users cannot control this; they expect a tool like autoconf to handle it.

The fundamental problem is that space has *TWO* conflicting meanings in 
autoconf:
1. Part of a path name.
2. Separator between arguments (including options)

It's reasonable to tell developers "do not put spaces in your source code 
filenames", but users
generally can't prevent spaces from being in the directory names in their 
environment.

I propose developing and documenting a standard convention for spaces in 
pathnames that
focuses on making things easier for *users* - the builders of the software.
This convention could be enabled by some statement in autoconf.ac, and perhaps
it could be enabled by default some time in the future.
If autoconf defined a simple convention for differentiating spaces in pathnames
from spaces in argument separators, it might "just work".  It'd be tricky to 
find such a convention,
but if one can be found, autoconf would be able to adapt to many common systems.

I propose the following convention, as a first cut:
1. Unquoted spaces continue to mean "argument separator".  This is by far the 
most common
use of spaces today, so making that the default meaning seems sensible.
2. Pathnames with spaces must use double-quotes in a way that enclose the spaces
(if they're passed in as configuration values or provided as probe results).

Any automatic search for a program (e.g., AC_CHECK_PROG and AC_CHECK_PROGS)
that found a pathname with spaces would surround the pathname
using double-quotes, but it would *not* surround the first few characters - 
instead, it could insert a double-quote
after the path separator that first *began* a component with spaces.
Since an automatically-generated pathname won't begin with double-quotes,
current scripts that look for "absolute pathnames"
by looking for "/" or "C:" at the beginning would keep working.
It'd be possible to use "\" in front of each space instead, but since variables 
go through
multiple processing steps through different tools, and "\" is a pathname 
separator
on Windows, I expect that backslash would be less robust than double-quotes.

The idea would be that generated Makefiles (for example) could look like this:
SBCL = /cygdrive/c/"Program Files/Steel Bank Common Lisp/1.2.6/sbcl"
EGREP = /usr/bin/grep -E
...
something.dest: something.src
  $(EGREP) ...
  $(SBCL) ...

I think this would require a relatively minor change in AC_CHECK_PROG,
and the result would be much better automation on many systems.

This is a slightly tricky problem; comments welcome.  It'd be nice to see
a simple and relatively clean solution to the problem.  I think "use 
double-quotes when
pathnames contain spaces" is a plausible answer.

--- David A. Wheeler