Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #5148 > unrolled thread

Escaping of line breaks for text replacement

Back to article view | Back to comp.unix.programmer

Contents

  Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-02 14:00 +0100
    Re: Escaping of line breaks for text replacement jt@toerring.de (Jens Thoms Toerring) - 2014-03-02 15:49 +0000
      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-03 08:38 +0100
    Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-02 16:52 +0000
      Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-02 17:53 +0000
        Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-02 20:27 +0000
          Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-03 16:17 +0000
            Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-03 17:44 +0000
              Re: Escaping of line breaks for text replacement Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2014-03-04 13:30 +0000
      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-02 20:50 +0100
        Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-03 16:52 +0000
      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-03 09:24 +0100
      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-03 12:55 +0100
        Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-03 17:02 +0000
          Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-06 12:02 +0100
            Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-06 18:51 +0000
              Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-06 20:48 +0100
                Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-06 22:59 +0000
                  Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-07 06:38 +0000
                    Re: Escaping of line breaks for text replacement Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-07 13:33 +0000
                    Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-07 15:08 +0000
                  Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-07 11:23 +0100
                    Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-07 14:43 +0000
                      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-07 17:23 +0100
                        Re: Escaping of line breaks for text replacement dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-07 19:53 +0000
                          Bash 4.3.0 escape expansion (was: Re: Escaping of line breaks for text replacement) dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-08 12:26 +0000
                            Re: Bash 4.3.0 escape expansion (was: Re: Escaping of line breaks for text replacement) Kaz Kylheku <kaz@kylheku.com> - 2014-03-08 20:05 +0000
                              Re: Bash 4.3.0 escape expansion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-09 03:48 +0000
                              Re: Bash 4.3.0 escape expansion dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-09 13:21 +0000
    Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-02 18:11 +0000
      Re: Escaping of line breaks for text replacement Markus Elfring <Markus.Elfring@web.de> - 2014-03-02 20:08 +0100
        Re: Escaping of line breaks for text replacement Kaz Kylheku <kaz@kylheku.com> - 2014-03-02 20:35 +0000
          Re: Which content should be escaped? Markus Elfring <Markus.Elfring@web.de> - 2014-03-03 10:30 +0100
            Re: Which content should be escaped? dave.gma+news002@googlemail.com.invalid (Dave Sines) - 2014-03-04 14:04 +0000
              Re: Which content should be escaped? Kaz Kylheku <kaz@kylheku.com> - 2014-03-04 17:32 +0000
    Re: Escaping of line breaks for text replacement Siri Cruz <chine.bleu@yahoo.com> - 2014-03-07 02:47 -0800

Page 1 of 2  [1] 2  Next page →

#5148 — Escaping of line breaks for text replacement

Hello,

I get the following result if I try out such a command on my openSUSE system.

elfring@Sonne:~> $SHELL --version && sed --version && LINE='echo ---' && $LINE \
&& DRAFT='template1.txt' && cat $DRAFT && $LINE \
&& INPUT='replacement1.txt' && cat $INPUT && XY=$(< $INPUT) && $LINE \
&& LANG=C sed "s/# placeholder/$XY/" $DRAFT
GNU bash, Version 4.2.45(1)-release (x86_64-suse-linux-gnu)
   ...
sed (GNU sed) 4.2.2
   ...
---
+++++++++++++
# placeholder
*************
---
ABC
XYZ
---
sed: -e expression #1, char 19: unterminated `s' command


I guess that the shown error message is an indication that I should add a bit of
escaping to the content of the variable "XY" which I inserted previously. I have
tried to achieve this with shell pattern substitution.

elfring@Sonne:~> XY=$(< $INPUT) && XY=${XY//\\\n/./} && echo $XY
ABC XYZ


I wonder why I do not get this approach to work so far with some additional
backslashes here. How should newlines be escaped for this purpose?

Would you like to share any further ideas?

Regards,
Markus

[toc] | [next] | [standalone]

#5150

In comp.unix.programmer Markus Elfring <Markus.Elfring@web.de> wrote:
> Hello,

> I get the following result if I try out such a command on my openSUSE system.

> elfring@Sonne:~> $SHELL --version && sed --version && LINE='echo ---' && $LINE \
> && DRAFT='template1.txt' && cat $DRAFT && $LINE \
> && INPUT='replacement1.txt' && cat $INPUT && XY=$(< $INPUT) && $LINE \
> && LANG=C sed "s/# placeholder/$XY/" $DRAFT
> GNU bash, Version 4.2.45(1)-release (x86_64-suse-linux-gnu)
>    ...
> sed (GNU sed) 4.2.2
>    ...
> ---
> +++++++++++++
> # placeholder
> *************
> ---
> ABC
> XYZ
> ---
> sed: -e expression #1, char 19: unterminated `s' command


> I guess that the shown error message is an indication that I should add a
> bit of escaping to the content of the variable "XY" which I inserted
> previously. I have tried to achieve this with shell pattern substitution.

Yes the problem is the linefeed in the replacement you pass to sed
in the end. You need to reolace the linefeeds read from the "re-
placements1.txt" file by '\\n' for sed to start to like them. One
way to do it would be e.g.

$SHELL --version && sed --version && LINE='echo ---' && $LINE &&
DRAFT='template1.txt' && cat $DRAFT && $LINE && INPUT='replacement1.txt' &&
cat $INPUT && XY=`sed ':a;N;$!ba;s/\n/\\\n/g' $INPUT` && $LINE && LANG=C sed
"s/# placeholder/$XY/" $DRAFT

With

XY=`sed ':a;N;$!ba;s/\n/\\\n/g' $INPUT`

you set XY to the files contents with linefeeds replaced by
'\\n' which is then acceptable to sed.

                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#5161

> XY=`sed ':a;N;$!ba;s/\n/\\\n/g' $INPUT`
> 
> you set XY to the files contents with linefeeds replaced by
> '\\n' which is then acceptable to sed.

Thanks for your suggestion.

I would prefer to perform such a search and replace operation for newlines by
the functionality "shell pattern substitution" instead of calling another
program. I am going to put a command variant into a make file so that I'm also
interested in considerations for relevant run time differences in the discussed
approaches.

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5151

[ Followup-To: set to comp.unix.programmer ]

Markus Elfring <Markus.Elfring@web.de> wrote:
> Hello,
> 
> I get the following result if I try out such a command on my
> openSUSE system.
> 
> elfring@Sonne:~> $SHELL --version && sed --version &&
> LINE='echo ---' && $LINE && DRAFT='template1.txt' && cat $DRAFT &&
> $LINE && INPUT='replacement1.txt' && cat $INPUT && XY=$(< $INPUT) &&
> $LINE && LANG=C sed "s/# placeholder/$XY/" $DRAFT

> GNU bash, Version 4.2.45(1)-release (x86_64-suse-linux-gnu)
>   ...
> sed (GNU sed) 4.2.2
>   ...
> ---
> +++++++++++++
> # placeholder
> *************
> ---
> ABC
> XYZ
> ---
> sed: -e expression #1, char 19: unterminated `s' command

DRAFT=template1.txt
REPLACEMENT=replacement1.txt

sed '/^# placeholder/{
r '"$REPLACEMENT"'
d
}' "$DRAFT"

Note the change from single to double quotes and back -- the script is
composed of three adjacent strings which will be concatenated by the
shell to form a single argument to sed.

> 
> I guess that the shown error message is an indication that I should
> add a bit of escaping to the content of the variable "XY" which I
> inserted previously. I have tried to achieve this with shell pattern
> substitution.
> 
> elfring@Sonne:~> XY=$(< $INPUT) && XY=${XY//\\\n/./} && echo $XY
> ABC XYZ
> 
> I wonder why I do not get this approach to work so far with some
> additional backslashes here. How should newlines be escaped for
> this purpose?

Use the shell's backslash-escape expansion ($'what\never').

It's not just newlines, any characters in the replacement text which
match sed's s command delimiter ('/' by default) will also need to
be escaped.

  XY=$(< "$REPLACEMENT" )
  XY=${XY//$'\n'/$'\\\n'}
  XY=${XY//\//\\\/}

  sed "s/# placeholder/$XY/" "$DRAFT"

[toc] | [prev] | [next] | [standalone]

#5152

On 2014-03-02, Dave Sines <dave.gma+news002@googlemail.com.invalid> wrote:
> It's not just newlines, any characters in the replacement text which
> match sed's s command delimiter ('/' by default) will also need to
> be escaped.

Almost right:

"any characters that are special in sed's regex syntax need to
be escaped."

(In the general case).

[toc] | [prev] | [next] | [standalone]

#5157

On 2014-03-02, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-03-02, Dave Sines <dave.gma+news002@googlemail.com.invalid> wrote:
>> It's not just newlines, any characters in the replacement text which
>> match sed's s command delimiter ('/' by default) will also need to
>> be escaped.
>
> Almost right:
>
> "any characters that are special in sed's regex syntax need to
> be escaped."

Actually that is not correct either, because this appears in the replacement
side of the regex. But there is some syntax there too like positional
references and & which have to be escaped.

[toc] | [prev] | [next] | [standalone]

#5169

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-03-02, Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2014-03-02, Dave Sines <dave.gma+news002@googlemail.com.invalid>
>> wrote:
>>> It's not just newlines, any characters in the replacement text which
>>> match sed's s command delimiter ('/' by default) will also need to
>>> be escaped.
>>
>> Almost right:

I have a slightly unhelpful tendency to assume anyone doing "s/foo/$BAR/"
is trying to manipulate pathnames.

>>
>> "any characters that are special in sed's regex syntax need to
>> be escaped."
> 
> Actually that is not correct either,

Yes it is.

> because this appears in the
> replacement side of the regex. But there is some syntax there too
> like positional references and & which have to be escaped.

The back-references can be considered part of the regular expression syntax.

[toc] | [prev] | [next] | [standalone]

#5172

On 2014-03-03, Dave Sines <dave.gma+news002@googlemail.com.invalid> wrote:
> Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2014-03-02, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> On 2014-03-02, Dave Sines <dave.gma+news002@googlemail.com.invalid>
>>> wrote:
>>>> It's not just newlines, any characters in the replacement text which
>>>> match sed's s command delimiter ('/' by default) will also need to
>>>> be escaped.
>>>
>>> Almost right:
>
> I have a slightly unhelpful tendency to assume anyone doing "s/foo/$BAR/"
> is trying to manipulate pathnames.
>
>>>
>>> "any characters that are special in sed's regex syntax need to
>>> be escaped."
>> 
>> Actually that is not correct either,
>
> Yes it is.
>
>> because this appears in the
>> replacement side of the regex. But there is some syntax there too
>> like positional references and & which have to be escaped.
>
> The back-references can be considered part of the regular expression syntax.

No, not really. Conceptually, the POSIX regex API returns an array of matches,
and this replacement side notation in the tools is a language for indexing into
that array to extract the matches into the substitution template.

These are not back-references.  Back-references are something which
occurs in the pattern-matching language itself (possibly rendering it non-regular).

A back-reference asserts "I'm a subexpression which matches the same thing as
another subexpression did earlier".

Confusion stems from backreferences in the pattern having the same syntax as
the replacement-side positional references, e.g. \1.

In any case, if you're interpolating strings into the replacement side of a s/a/b/
command, you do not have to escape the regex operators like ? or +. You have
to escape the replacement-side operators.

  $ sed -e 's/a/*/'
  a
  *

See? * is just itself; so we don't need \* to insert a literal *. Different language.

[toc] | [prev] | [next] | [standalone]

#5173

Kaz Kylheku wrote:

> In any case, if you're interpolating strings into the replacement side
> of a s/a/b/ command, you do not have to escape the regex operators
> like ? or +. You have to escape the replacement-side operators.
> 
>   $ sed -e 's/a/*/'
>   a
>   *
>
> See? * is just itself; so we don't need \* to insert a literal *.
> Different language.

Nit-pick: that's a poor example to choose as illustration, since
a * at the beginning of a BRE is treated as a literal * anyway:

$ echo 'a*b' | sed -e 's/*/x/'
axb

-- 
Geoff Clare <netnews@gclare.org.uk>

[toc] | [prev] | [next] | [standalone]

#5156

>> I wonder why I do not get this approach to work so far with some
>> additional backslashes here. How should newlines be escaped for
>> this purpose?
> 
> Use the shell's backslash-escape expansion ($'what\never').

Is the shell pattern substitution alone really insufficient for the requested
use case?


> It's not just newlines, any characters in the replacement text which
> match sed's s command delimiter

Thanks for your reminder.


> ('/' by default)

Would you like to indicate here that this special character can eventually be
adjusted by a parameter or environment variable?


> will also need to be escaped.

I am going to consider this detail for further fine-tuning of the passed values.

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5170

Markus Elfring <Markus.Elfring@web.de> wrote:
>>> I wonder why I do not get this approach to work so far with some
>>> additional backslashes here. How should newlines be escaped for
>>> this purpose?
>> 
>> Use the shell's backslash-escape expansion ($'what\never').
> 
> Is the shell pattern substitution alone really insufficient for the
> requested use case?

XY='one
two
three
four'

If you don't mind using embedded newlines in the substitution:

Z=${XY//'
'/'\
'}

Or

nl='
'

Z=${XY//"$nl"/"\\$nl"}

> 
> 
>> It's not just newlines, any characters in the replacement text which
>> match sed's s command delimiter
> 
> Thanks for your reminder.

See Kaz' post for a correction to that -- there are other characters
(and sequences) which would cause errors if they appear in the replacement
text.

  $ foo="&&"
  $ echo "error" | sed "s,r,$foo,g"
  errrrorr
  $ foo='\1'
  $ echo "error" | sed "s,r,$foo,g"
  sed: -e expression #1, char 8: invalid reference \1 on `s' command's RHS

> 
>> ('/' by default)
> 
> Would you like to indicate here that this special character can
> eventually be adjusted by a parameter or environment variable?

sed accepts any character as delimiter for the substitution command
making it possible to use any character which is known not to appear
in the replacement text.

Here with a comma:

  sed "s,something,${XY},g"

If you need it to be adjustable:

  sep=:
  sed "s${sep}something${sep}${XY}${sep}g"

[toc] | [prev] | [next] | [standalone]

#5162

> sed '/^# placeholder/{
> r '"$REPLACEMENT"'
> d
> }' "$DRAFT"
> 
> Note the change from single to double quotes and back -- the script is
> composed of three adjacent strings which will be concatenated by the
> shell to form a single argument to sed.

Thanks for your command example. I find this approach also interesting.
But I do not like the documented constraint for my use case.

http://www.gnu.org/software/sed/manual/html_node/Other-Commands.html :
"...
Note that if filename cannot be read, it is treated as if it were an empty file,
without any error indication.
.."

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5164

>> How should newlines be escaped for this purpose?
> 
> Use the shell's backslash-escape expansion ($'what\never').

I guess that a bit more "fun" is needed around the topic "leaning toothpick
syndrome" to achieve the expected result, isn't it?   ;-)

elfring@Sonne:~> XY=$(< $INPUT) && sed "s%# placeholder%${XY//$'\n'/$'\\\\\n'}%"
$DRAFT
+++++++++++++
ABC
XYZ
*************

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5171

Markus Elfring <Markus.Elfring@web.de> wrote:
>>> How should newlines be escaped for this purpose?
>> 
>> Use the shell's backslash-escape expansion ($'what\never').
> 
> I guess that a bit more "fun" is needed around the topic "leaning toothpick
> syndrome" to achieve the expected result, isn't it?   ;-)
> 
> elfring@Sonne:~> XY=$(< $INPUT) &&
>                  sed "s%# placeholder%${XY//$'\n'/$'\\\\\n'}%" $DRAFT

Oh!  You know about alternative delimiters.

> +++++++++++++
> ABC
> XYZ
> *************

Just to add to the, er, amusement: capturing output strips trailing blank
lines:

  XY=$(cat << EOF
there are three blank
lines at the end of this



EOF
)

  printf 'X%sY\n' "$XY"

[toc] | [prev] | [next] | [standalone]

#5176

> You know about alternative delimiters.

Would you like to look at another concrete application of the discussed
implementation details?
https://systeme.lip6.fr/pipermail/cocci/2014-March/000680.html
http://article.gmane.org/gmane.comp.version-control.coccinelle/3517

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5177

Markus Elfring <Markus.Elfring@web.de> wrote:
>> You know about alternative delimiters.
> 
> Would you like to look at another concrete application of the discussed
> implementation details?
> https://systeme.lip6.fr/pipermail/cocci/2014-March/000680.html
> http://article.gmane.org/gmane.comp.version-control.coccinelle/3517

Thanks, I was wondering why you needed the extra backslashes. :)

+SED=sed

+RESULT_FUNCTIONS_WITH_PREFIX=add_prefix-SQL.txt

+LIST_PATTERN_TEMPLATE=list_functions_with_unnecessary_checks_template1.cocci
+LIST_PATTERN=list_functions_with_unnecessary_checks1.cocci
+PATCH_PATTERN_TEMPLATE=delete_unnecessary_checks_template1.cocci
+PATCH_PATTERN=delete_unnecessary_checks1.cocci

+ESCAPING=XY=$$(< $(RESULT_FUNCTIONS_WITH_PREFIX)) \
+         && XY=$${XY/|/ } \
+         && XY=$${XY//%/\\%} \
+         && $(SED) "s%\# Alternation placeholder%$${XY//$$'\n'/$$'\\\\\n'}%"

+$(LIST_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+	$(ESCAPING) $(LIST_PATTERN_TEMPLATE) > $@
+
+$(PATCH_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
+	$(ESCAPING) $(PATCH_PATTERN_TEMPLATE) > $@


Using some dummy input files derived from elsewhere in this thread and a
Makefile modelled on the above fragment, I'm seeing inconsistent results
when make invokes different versions of bash (and bash-as-/bin/sh).
Moving the shell substitution with escape expansions out of the double-
quoted string seems to fix this.

This line:

         && $(SED) "s%\# Alternation placeholder%$${XY//$$'\n'/$$'\\\\\n'}%"

Becomes:

         && XY=$${XY//$$'\n'/$$'\\\\\\n'}     \
         && $(SED) "s%\# Alternation placeholder%$${XY}%"

[toc] | [prev] | [next] | [standalone]

#5178

> Using some dummy input files derived from elsewhere in this thread and a
> Makefile modelled on the above fragment, I'm seeing inconsistent results
> when make invokes different versions of bash (and bash-as-/bin/sh).

Thanks for your interest and feedback.

Would you like to tell a bit more about the bash versions you try out?


> Moving the shell substitution with escape expansions out of the double-
> quoted string seems to fix this.

I hoped that I could avoid an intermediate variable assignment. I am surprised
that I might stumble on a portability issue here.

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#5179

Markus Elfring <Markus.Elfring@web.de> wrote:
>> Using some dummy input files derived from elsewhere in this thread and a
>> Makefile modelled on the above fragment, I'm seeing inconsistent results
>> when make invokes different versions of bash (and bash-as-/bin/sh).
> 
> Thanks for your interest and feedback.
> 
> Would you like to tell a bit more about the bash versions you try out?

4.3.0, 4.2.37, 4.2.20, 4.1.9, 4.0.35, 3.2.48, 3.1.17, 2.05b.7.

Here's a demo Makefile (it creates r.txt and t.txt in the working directory)

#v+
SED = sed

REPL = r.txt
TMPL = t.txt

ESCAPING1 = XY=$$(< $(REPL) )                 \
        && echo $$BASH_VERSION                \
        && XY=$${XY//$$'\n'/$$'\\\\\\n'}      \
        && $(SED) "s%\# placeholder%$${XY}%"

ESCAPING2 = XY=$$(< $(REPL) )                 \
        && echo $$BASH_VERSION                \
        && $(SED) "s%\# placeholder%$${XY//$$'\n'/$$'\\\\\\n'}%"

works:
	$(ESCAPING1) $(TMPL)

fails:
	$(ESCAPING2) $(TMPL)

$(REPL):
	printf 'ABC\nXYZ\n' > $(REPL)

$(TMPL):
	printf '++++\n# placeholder\n++++\n' > $(TMPL)

.SILENT:
#v-

/bin/sh is a symlink to bash.  /bin/bash and /bin/bash-4.3 are bash
4.3.0(1)-release.  make is GNU Make 4.0.  sed is GNU sed 4.2.2.

$ make works
4.3.0(1)-release
++++
ABC\
XYZ
++++
$ make fails
4.3.0(1)-release
sed: -e expression #1, char 19: unterminated `s' command
Makefile:20: recipe for target 'fails' failed
make: *** [fails] Error 1

Note that the "fails" target works when SHELL is not /bin/sh:

$ make SHELL=/bin/bash-4.3 fails
4.3.0(1)-release
++++
ABC\
XYZ
++++

With /bin/sh as a symlink to /bin/bash-4.2.37.

$ make works
4.2.37(1)-release
++++
ABC\
XYZ
++++
$ make fails
4.2.37(1)-release
++++
ABC\nXYZ
++++
$ make SHELL=/bin/bash-4.2.37 fails
4.2.37(1)-release
++++
ABC\nXYZ
++++

Bash versions 3.1.17, 3.2.48, 4.0.35, 4.1.9, and 4.2.20 match the behaviour
of 4.2.37.

With /bin/sh linked to bash 2.05b the output from the "fails" target
target differs slightly:

$ make works
2.05b.0(1)-release
++++
ABC\
XYZ
++++
$ make fails
2.05b.0(1)-release
++++
ABC'\n'XYZ
++++

>> Moving the shell substitution with escape expansions out of the double-
>> quoted string seems to fix this.
> 
> I hoped that I could avoid an intermediate variable assignment. I am
> surprised that I might stumble on a portability issue here.

Is awk acceptable?  I *think* the following fragment should work in your
Makefile (<https://systeme.lip6.fr/pipermail/cocci/2014-March/000680.html>).

#v+
AWKPROC = awk '                                                         \
        NR == FNR { sub(/[|]/, " ") ; s = s n $$0 ; n = "\\\n" ; next } \
        /\# Alternation placeholder/ { $$0 = s }                        \
        { print }'

$(LIST_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
	$(AWKPROC) $< $(LIST_PATTERN_TEMPLATE) > $@

$(PATCH_PATTERN): $(RESULT_FUNCTIONS_WITH_PREFIX)
	$(AWKPROC) $< $(PATCH_PATTERN_TEMPLATE) > $@
#v-

Change the assignment 'n = "\\\n"' to 'n = "\n"' if you don't want the
newlines within the substitution to be escaped in the output files.

[toc] | [prev] | [next] | [standalone]

#5180

On 2014-03-06, Dave Sines <dave.gma+news002@googlemail.com.invalid> wrote:
> Here's a demo Makefile (it creates r.txt and t.txt in the working directory)
>
> #v+

What is this? Both my news-reader and editor recognize it and colorize
the stuff between. Some de-facto standard delimiting "verbatim" blocks?
Is this in some RFC?

-- 
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List:  http://www.kylheku.com/mp1

[toc] | [prev] | [next] | [standalone]

#5183

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2014-03-06, Dave Sines <dave.gma+news002@googlemail.com.invalid> wrote:
>> Here's a demo Makefile (it creates r.txt and t.txt in the working directory)
>>
>> #v+
>
> What is this? Both my news-reader and editor recognize it and colorize
> the stuff between. Some de-facto standard delimiting "verbatim" blocks?
> Is this in some RFC?

Good question.  My I've known for a while that newsreader recognises
these marks, but I've never known how widely supported they are and
hence how useful they are.  It seems that at least tin, slrn and gnus
support them.  Google groups just shows them like any other line.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web