Follow-up Comment #6, bug #35063 (project make): I think the root of our disagreement is in the goals. This is not at all about adding url encode/decode capability to make; it's about a consistent, safe way of getting special characters past the make parser and I suggested url encoding (aka percent-encoding) as a well-known mechanism which is easy to implement. Another encoding would serve just as well.
In particular, there's no call for url _encoding_ support as I see it. If you can make a case that there's a reason to support both then maybe your proposal would be better. But that's not the stated goal here. Your question about 'Hello%2C%20world%21' is answered in the original proposal; if the variable reference begins with '$(%' then the string is subjected to standard url decoding, which is well defined to produce "Hello, World!". WRT special functions I think the choices are pretty clear. Given that %3A is a colon: $(call %3A) returns : $(value %3A) returns : $(origin %3A) returns default $(flavor %3A) returns simple In essence $(%2C) is defined to behave exactly as if the line %2C := , had been seen (actually not quite, it would be in the list of predefined variables such that --no-builtin-variables would suppress the feature). BTW see <http://www.cmcrossroads.com/ask-mr-make/8442-gnu-make-escaping-a-walk-on-the-wild-side> for some background on the problem. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?35063> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
