bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sus behaviour when cmd string ends with single backslash


From: Zoltan Vajda
Subject: Re: Sus behaviour when cmd string ends with single backslash
Date: Mon, 14 Feb 2022 22:05:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0


vzvzvz2@gmail.com writes:
The mentioned bug is indeed fixed by this change. However, in case of
another edge case following new behaviour is observable:

  $ bash -c 'echo \'
  \
  $ # backslash appears on output
It's an interesting case, since the command that Bash is executing is
e-c-h-o-space-backslash
with no character at all after the backslash.  The manual page says

        A non-quoted backslash (\) is the escape character.  It  preserves  the
        literal value of the next character that follows, with the exception of
        <newline>.  If a \<newline> pair appears, and the backslash is not  it-
        self quoted, the \<newline> is treated as a line continuation (that is,
        it is removed from the input stream and effectively ignored).

Which doesn't seem to consider this case at all.

The two a-priori plausable behaviors are for the backslash to be taken
literally (which is what happens) or for it to vanish as some sort of
incomplete escape construct.

So you could plausibly say that the behavior of a backslash before "end
of file" isn't defined.

Dale

As you cited, a non-quoted backslash preserves the literal value of the next
character. Therefore, backslash cannot be literally taken. The next character is "nothing" (or EOF), so if we take the documentation literally :), the backslash should preserve this "nothing" (or EOF). This would comply with the definition
very well.

Zoltan





reply via email to

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