Re: test for newline in a variable--unexpected results sometimes

[dana <dana@dana.is>]

On 16 Sep 2018, at 15:44, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>In this context, «\n» does not mean a newline; it means either the letter 'n',
>or the two-character sequence «\n», but I don't remember which.

I was about to hit send on an answer to this but you addressed it. Here's a more
detailed explanation of this part (the effects of quoting):

* In an UNQUOTED string, all slash-escaped characters produce the literal
  version of the character being escaped:

  \\  ->  \
  \$  ->  $
  \1  ->  1
  \n  ->  n

* In a DOUBLE-QUOTED string, slash-escaped shell meta-characters produce the
  literal version of the character being escaped. Any other back-slash is left
  as-is:

  "\\"  ->  \
  "\$"  ->  $
  "\1"  ->  \1
  "\n"  ->  \n

* In a SINGLE-QUOTED string, all back-slashes are left as-is:

  '\\'  ->  \\
  '\$'  ->  \$
  '\1'  ->  \1
  '\n'  ->  \n

* In a DOLLAR-QUOTED string, escape sequences are interpreted according to the
  default behaviour of the print built-in, which supports various C-style
  sequences amongst other things. Sequences that aren't handled specifically are
  treated as they are in unquoted strings:

  $'\\'  ->  \
  $'\$'  ->  $
  $'\1'  ->  (ASCII character with octal code point 001)
  $'\n'  ->  (ASCII new-line)

This is mostly covered by the Shell Grammar section of the manual, though it's
not quite as explicit

dana