Re: variables with spaces

[Paul D. Smith]

%% "Eli Zaretskii" <address@hidden> writes:

  >> Then the question becomes how to encode them?  I was playing with the
  >> idea of replacing space characters with some control character, like
  >> ASCII 0x01 or something.  Then none of the make parsing functions would
  >> treat it like whitespace, and we'd just have to translate it back again
  >> before printing it.  It also has the advantage that the string is the
  >> same length before and after encoding/decoding.
  >> 
  >> Then I realized that make support multiple locales and some of the
  >> charsets people might use to write makefiles in might use control chars
  >> like 0x01.  I'm not very familiar with that so I can't say whether it
  >> would be true or not... Eli, you probably are much more able than I to
  >> talk about whether this is viable or not.

  ez> Is it possible to use some sequence of ASCII characters which are
  ez> unlikely to appear in a filename, to encode a whitespace?

Anything's possible.  The problems with this are:

 a) What do you do when someone _does_ have that sequence of ASCII
    chars?

 b) As mentioned above, having the before and after parsing strings be
    different lengths may mean more work in the code.

 c) Even this doesn't keep us from having to add _some_ amount of
    special checks, because functions like $(subst ...) etc. might break
    it.

    Consider if you used the sequence "address@hidden" or something, then 
someone
    used $(subst x,a,...) on your string??

That's why I wanted to use a control character which could never appear
(within reason) in a real string that we'd read from a makefile or from
the disk.  This way we'd know the only way that character could ever
have appeared in a string internal to make was through this translation
method.  It seemed like ASCII 0x01 or similar would be ideal.

But then I considered locale support and I wasn't so sure anymore.

GNU make actually doesn't support multi-character strings--although I
suppose they might work by accident in some cases?  Not sure.

  ez> If not, then the only alternative seems to be to escape the blanks
  ez> with something like \, and then have lots og hairy code to deal
  ez> with that.  Yikes; but what else could one do?  Unix users don't
  ez> even have the 8+3 short alias ``work-around''.

This is why I haven't even attempted this approach.  The fact is it's
simply far too much work for not enough return, in my (admittedly highly
UNIX-centric) opinion.  Up until now I've simply told people who
couldn't live without spaces in filenames that they needed to go look
for a different tool.  It sounds harsh, but realistically this work is
not something I'm willing to undertake.

I've not heard complaints from UNIX users: virtually none of them use
whitespace in filenames (it's a pain to deal with in UNIX because it
requires extra shell quoting).  If you have to use them (generally
because some broken tool generates the filenames for you) you can use
hacks like symlinks, which aren't available in Windows.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist