On Sun, Mar 16, 2025 at 1:12 AM Robert Elz <k...@munnari.oz.au> wrote: > > | bash(1) claims it to be: > > Actually, I don't think it does, > > | There are three quoting mechanisms: the escape character, single > | quotes, and double quotes. > | > | A non-quoted backslash (\) is the escape character. It preserves > | the literal value of the next character that follows, > > That is \ being the escape char.
Exactly: "A non-quoted backslash (\) is the escape character." Full stop. > > | with the exception of <newline>. > > And that's the exception, when \ isn't the escape char, There is no exception to backslash being the escape character. The exception is to "It preserves the literal value of the next character that follows", hence the phrase being part of the same sentence. Which declares the backslash escaping/interpreting any character one way (literal), EXCEPT the newline, which it escapes/interprets a different way (line continuation). > > | the \<newline> is treated as a line continuation > > it is that instead. But this is just terminology, what we > call it makes no difference, it does what it does. Agreed. > > | I do not see any exceptional circumstances in the above description of > | line continuation in bash(1), which implies there are none, which > | implies it is stating "it as working", without exception. > > There aren't any exceptions in general, line continuation applies > everywhere an unquoted (or double quoted) including in here-docs > with an unquoted delimiter word in the operator. > > The question is whether that is done before or after the end delimiter > is tested when reading the here doc, which POSIX says is unspecified, and > the bash doc says nothing about at all. > "the bash doc says nothing about at all" Exactly. It specifies line continuations unconditionally. All I'm saying is that if you're going to disclaim this use case, then it seems worth including in the doc to warn others. Otherwise the user is left to assume bash will do exactly what the doc says it will do, *unconditionally*. On Sun, Mar 16, 2025 at 1:12 AM Robert Elz <k...@munnari.oz.au> wrote: > > Date: Sat, 15 Mar 2025 21:54:18 -0500 > From: MacBeth <macbeth.112...@gmail.com> > Message-ID: > <cagp4wjwdv8i+55+6rsmeuxsqf4uvpphxr+hvwpva8_gn4bo...@mail.gmail.com> > > | bash(1) claims it to be: > > Actually, I don't think it does, > > | There are three quoting mechanisms: the escape character, single > | quotes, and double quotes. > | > | A non-quoted backslash (\) is the escape character. It preserves > | the literal value of the next character that follows, > > That is \ being the escape char. > > | with the exception of <newline>. > > And that's the exception, when \ isn't the escape char, > > | the \<newline> is treated as a line continuation > > it is that instead. But this is just terminology, what we > call it makes no difference, it does what it does. > > | I do not see any exceptional circumstances in the above description of > | line continuation in bash(1), which implies there are none, which > | implies it is stating "it as working", without exception. > > There aren't any exceptions in general, line continuation applies > everywhere an unquoted (or double quoted) including in here-docs > with an unquoted delimiter word in the operator. > > The question is whether that is done before or after the end delimiter > is tested when reading the here doc, which POSIX says is unspecified, and > the bash doc says nothing about at all. > > kre > > >
