Re: line continuation with sed

[Lawrence Velázquez <larryv@xxxxxxx>]

On Thu, Oct 13, 2022, at 2:25 PM, Ray Andrews wrote:
> I'm wondering if this is a zsh issue or entirely sed's fault but:
>
> $ var=$( print -l $var | sed \
> -re 's/.../' \                                 # this is fine
> -re 's/.../'\                                  # this  throws an error 
> which I'd expect
> -re 's/.../' \                                  # this throws an error ...
> -re 's/.../' )

As an aside, you only need to specify -r (or -E) once.  Repeating
it has no effect.

> ... if there is a bloody space AFTER the backslash and before the 
> newline.  Thing is it's an invisible error, I just wasted the morning 
> with some sed errors which refused to be found because they were 
> invisible.  What logic would make a space before the newline an error?  
> I'm thinking it must be a zsh issue because zsh is responsible for line 
> continuation.

It is not an "issue", but zsh is indeed responsible.

> Multiple spaces between sed expressions are fine as one 
> would expect so if the backslash simply wrapped the line, there should 
> be no issue.  Mind, haven't I whined about this before?  Could there 
> ever be a situation where backslash-space-newline was not logically 
> reducible to backslash-newline?

What makes you think they are equivalent?  They are not.

https://zsh.sourceforge.io/Doc/Release/Shell-Grammar.html#Quoting

	A character may be quoted (that is, made to stand for itself)
	by preceding it with a '\'.  '\' followed by a newline is
	ignored.

So the sequence \ SP LF is a quoted space followed by an unquoted
line feed.  In this example (and your original), the latter acts
in its common capacity as a sublist terminator:

	% eval $'printf "<%s>\n" foo \\\nbar'
	<foo>
	<bar>
	% eval $'printf "<%s>\n" foo \\ \nbar'
	<foo>
	< >
	zsh: command not found: bar

-- 
vq