make-alpha
[Top][All Lists]
Advanced

[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: Sun, 23 Feb 2014 05:53:13 +0200

> Date: Sat, 22 Feb 2014 22:18:15 +0100
> Cc: address@hidden
> From: Frank Heckenbach <address@hidden>
> 
> Eli Zaretskii wrote:
> 
> > > So, while quoting may look natural in the makefile, it doesn't help with
> > > the issues Frank raised regarding writing recipes correctly when paths
> > > contain special characters: we'd be stripping that quoting before
> > > running the recipe in any event.
> > 
> > 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.
> 
> The problem is how to quote them for a command line. In bash (and I
> think any POSIX shell, but I'm not even sure of that), you can quote
> an arbitrary string, but not in a uniform way. There are several
> ways to do that, the simplest one (AFAIK) is to put '' around the
> string and handle ' within the string specially (close the ', quote
> the actual ' with a \, start a new ' quote for the rest of the
> string, because \ does not escape within ''; therefore the
> Q='$(subst ','\'',$(1))' in my previous mail).

I know about these problems (and others), and that's why I say that
Make shouldn't even attempt to solve them.  It's up to the user.

> Yet, as I said, I'd like to see a solution to this problem. So even
> if it's not possible in a fully automatic way, the next best thing
> is to require as little user intervention as possible.

I don't see why these requirements should be in our way of allowing
whitespace in strings.  They make the goal unnecessarily harder to
achieve.

> > If we know that a variable was quoted, we will treat it as a single
> > word.  So I don't really see any serious problems here (of course,
> > this special handling of quoted strings will have to be coded).
> 
> Unfortunately, it's not so easy. In my example above, the value
> could neither be words-separated-by-spaces like now (would become 4
> words), nor a single word as you suggest.

This is only a problem because you want to solve the quoting issue at
the same time.  If you remove that requirement, the problem goes away.

> > > Using backslashes has similar problems, especially on Windows
> > > systems where you might expect backslashes to be used in variables
> > > as a matter of course.
> >
> > No, there are no problems on Windows, because file or directory names
> > on Windows do not _start_ with blanks.
> 
> Is this actually forbidden or just by convention?

It's almost forbidden: you need to work hard to get such names, and
many functions/features will fail if you do.

> Even if so, what about a case like this:
> 
> foo:
>       rsync c:\foo\ c:\bar\

What about it?  I'm probably missing something (because I don't use
rsync).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]