bug-bash
[Top][All Lists]
Advanced

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

Re: ${p+\"$p\"}


From: Robert Elz
Subject: Re: ${p+\"$p\"}
Date: Mon, 21 Jan 2019 23:38:22 +0700

    Date:        Mon, 21 Jan 2019 09:37:02 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <de2a733a-0d8e-2181-ead6-2729664aca2f@case.edu>

  | It's the here-document. Backslashes and double quotes in here documents are
  | kind of strange. This is historical sh behavior.

Not so much backslashes, a here doc (this form) is just a double
quoted string, and \ behaves in it like in any other double quoted
string - escaping the special chars, and otherwise simply being
left alone.

What is odd is that even though it is a double quoted string, the
double quote character is just a character, and has no quoting
effects at all.  And as it is not special, the \" combination is
simply the two characters \ and ".

This really gets ugly when var expansions (the old forms, not the
new pattern matching ones, or any of the ones that are not posix
which bash supports) which was being used in this case.   Quoting
inside a double quoted string, inside a var expansion is bad enough
on the command line, in a here doc it is just a disaster.

For what it is worth, both bosh and the FreeBSD shell
produce

\"A\"
"A"

as the results of the script provided, and I think that is technically
correct according to posix.   If the '"' chars were anything else
(say a % or something otheriwse meaningless) then there is no
doubt that is what should be produced, and essentially all shells
(bash included) do exactly that (that is, the above with the "
changed to % or whatever was chosen.)  As the "s are supposed
to be "just another character" here, they ought to act just the same
as a % would act.

With the quotes, most other shells produce the output reported
from dash (that includes ksh93, yash, ...)   zsh just says it iis
a parse error, which is probably a rational choice!

Nothing else I tested produces what bash does, which does seem
to be a kind of odd pair of results.

But this is an area that is a monumantal mess, and the only rational
choice is to find some workaround which does not involve putting
a " inside a var expansion inside a here doc.

kre




reply via email to

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