Re: SUBST_SED and newline?

[Roland Illig <roland.illig%gmx.de@localhost>]

Georg Schwarz schrieb:
> Am 09.12.2009 um 23:43 schrieb fulvio ciriaco:
>
> > I guess it involves SUBST_SED being invoked inside a higher
> > substitution level and that one needs to escape one level more,
>
>
> probably. However, I think in that case any multiple escaping tricks 
> should be avoided because they could easily break on any slight change 
> of the buildlink infrastructure.

I don't think so. Once the developer understands which escaping is 
necessary at exactly which place, it isn't that complicated anymore, and 
this behavior is even supported by POSIX. So let's start: We want to 
have a sed command that surrounds each line "#include <sys/io.h>" with 
an #if...#endif block. The basic syntax for this is:

s,^#include <sys/io\.h>,#ifndef __sun\
#include <sys/io.h>\
#endif,

The backslashes at the line ends are required by sed, as explained in 
the POSIX manpage.

Now let's convert this string into a valid bmake string, for use in a 
variable assignment. This means that every # has to be escaped as \#, 
and the newline has to be written as ${.newline}. Nothing more:

SUBST_SED.sysio+= -e 's,^\#include <sys/io\.h>,\#ifndef 
__sun\${.newline}\#include <sys/io.h>\${.newline}\#endif,'

(the above is meant to be a single line of code.)

The difference to Georg's suggestion is the single backslash, not the 
double backslash before the ${.newline}. Like that, it works fine for me 
here on Interix, and probably everywhere else.

The double backslashes don't work because sed still sees them as double 
backslashes, so it interprets the ${.newline} that follows immediately 
as a real newline and not as an escaped one.

(Maybe I should teach pkglint to analyze this kind of problems the same 
was as I just did. Or would that be overkill? ;))

Roland