[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Quoting special characters (was: Re: Possible solution for special c
From: |
Eli Zaretskii |
Subject: |
Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths) |
Date: |
Sat, 22 Feb 2014 20:35:59 +0200 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Sat, 22 Feb 2014 13:15:46 -0500
>
> Suppose I have a variable like this:
>
> FOO = "foo bar" " biz " "foo\baz"
>
> Now I write:
>
> all: $(FOO)
> $(FOO): ; @echo "'$(firstword $@)'"
>
> What do we expect the output to be?
'foo bar'
> What if instead I do this:
>
> OUTPUT := $(patsubst %,echo '%' ;,$(FOO))
> all: ; @$(OUTPUT)
>
> ??
I'm sorry, but I don't see the problem. Please be more explicit, I'm
not as fluent with Make tricks as you are.
> What if I do this:
>
> SHELL = /usr/bin/python
> all: $(FOO)
> $(FOO): ; @print """$@"""
>
> ??
Why is that our problem? _The_User_ must set up the quotes in the
command line; we cannot do this for them. And anyway, how will your
other suggestion solve these same problems?
> > First, we don't _have_ to strip them; we could keep the quotes. And
> > second, we could strip them, but record in the variable that it was
> > quoted. In both cases, we will restore the quoting in the context
> > that needs them, such as when they are part of a shell command line.
>
> Restore what quoting? What if SHELL is set to R, or Ruby, or Lisp, or
> something with very different quoting rules than whatever make
> understands?
Then we leave the string unquoted; the user will have to do that.
> That doesn't change the fact that make may have to chop the strings
> up into words to do its job.
A quoted string is a single word.
> You're basically saying that make would need to understand the quoting
> rules for any interpreter SHELL is set to
No, only for the shells it understands now and whose quoting it
already supports on the command lines.
> Make must have its own out-of-band quoting syntax, because we cannot
> use the interpreter's quoting syntax.
I think we can do this for the shells whose quoting we understand now.
> > Why should we bother about these hypothetical use cases? Are there
> > any real-life Makefiles that do anything like that? If there are,
> > let's look at them, and let's understand why they need this quote
> > juggling in the first place.
>
> No matter how unlikely a given make sequence may look to us, someone,
> somewhere will be doing it.
That goes for your other suggestion as well. So, in itself, this
isn't an argument for or against my suggestion.
> > Exactly my point: using a backslash to escape a blank is a natural
> > extension of what we already do with a colon. I fail to see why is it
> > so different.
>
> It's a huge compatibility problem. Let's take a more realistic example.
> Suppose you wanted to have a variable containing two words, "foo\" and
> "bar". Today you write this:
>
> FOO = foo\ bar
>
> Now if you want to use this as a list of targets (we'll say they're
> phony to avoid issues with real filenames, although "foo\" is a
> perfectly valid POSIX filename):
>
> .PHONY: all $(FOO)
> all: ; $(FOO)
> $(FOO): ; @echo '$@'
>
> Running "make 'foo\'" is perfectly valid. And maybe you want to massage
> these into URLs (having backslashes in URLs is pretty common, even
> today):
>
> all: ; for a in $(patsubst %,'http:\\%',$(FOO)); do echo "$$a"; done
>
>
> Now we come along with the next release of GNU make, and say that if a
> space is prefixed with a backslash it's no longer a word separator, but
> instead a literal space, and instead of two words, FOO is now the single
> word "foo bar". If you want "foo\" and "bar" you have to modify your
> makefile:
>
> FOO = foo\\ bar
>
> Right?
It's one possibility, yes. Why is that a problem? Don't we have such
a problem already with files that include colons?
- Possible solution for special characters in makefile paths, Paul Smith, 2014/02/20
- Re: Possible solution for special characters in makefile paths, Frank Heckenbach, 2014/02/21
- Re: Possible solution for special characters in makefile paths, Paul Smith, 2014/02/21
- Re: Possible solution for special characters in makefile paths, Eli Zaretskii, 2014/02/22
- Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/22
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Eli Zaretskii, 2014/02/22
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/22
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths),
Eli Zaretskii <=
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/22
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Eli Zaretskii, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Eli Zaretskii, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Eli Zaretskii, 2014/02/24
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/24
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Frank Heckenbach, 2014/02/24
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/25
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Frank Heckenbach, 2014/02/25