Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths)
Eli Zaretskii <[email protected]>
| Newsgroups | gmane.comp.gnu.make.devel |
|---|---|
| Message-ID | <[email protected]> |
> From: Paul Smith <[email protected]> > Date: Tue, 25 Feb 2014 13:11:28 -0500 > Cc: [email protected] > > My original proposal was a complete solution, and so it covered this. > To sum it up (you can go check the original email for a more in-depth > discussion): > > On parsing $[...] (wherever it appears) we would encode the string "..." > so that any special characters like whitespace, etc. are encoded into > values that weren't special to make. I proposed using bytecodes like > 001, 002, etc. but there are other options. This is very like the > $(quote ) etc. function that has been proposed, except with a shorter > syntax. > > The encoding of the string internally allows all current make functions > to go unmodified, because they're all searching for whitespace (for > example) and those characters wouldn't be whitespace anymore. As you > point out, the encoding is an implementation detail so not really > relevant to the UI. > > We would proceed without change from today's behavior all the way > through to the very last step right before we actually invoked the > command to run. In the slow path that means we've built up a string, > expanded all variables, etc. etc. Right then, the very last thing we do > before we pass the string to system() (or whatever on make ports), we > decode that string and turn the special characters back into whitespace > or whatever they were before. > > If we took the fast path, then after we'd broken up the string into argv > and just before we called fork/exec (or whatever on the make ports), we > would decode each value of argv individually. > > Ditto for setting the environment. > > There would be no attempt to add any shell quoting around special > characters into the recipe, that would be up to the user. OK, thanks for explaining this (again). As I already wrote, I think it would be better to keep the whitespace internally as well, instead of encoding it. If nothing else, it will be confusing when debugging Make, and will probably require custom commands to print strings. And there's a real danger of leaking these encoded strings to the outside world.