Thank you Nick. So here's the one I just found.
In the section 2.2.3 Double-Quotes, it says about \ : "The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special: $ ` " \ <newline> " Issue 1. This statement is not really clear, about what it means "considered special". I guess it means "special" if the preceding backslash (and other immediately preceding backslashes) _were_not_there_. For if it meant with the backslash in place, then the question "is it special" would depend on whether the backslash is special, which is what we are deciding, a circular dependency. But I think this should really be clarified - phrase such as "if preceding backslash(es) were not there" should be added. So I am going to assume "if preceding backslash(es) were not there". Issue 2. Well, inside double-quotes, newline by itself is _not_ considered special (by bash and dash). The "special" meaning of newline is that the NEWLINE token has certain effects during parsing, for example, it ends a simple command. But it does not in this situation: bash> echo "foo > So according to above statement, inside double-quotes, in the sequence <backslash><newline>, backslash should _not_ be an escape character as meant in section 2.2.1 . Therefore, this sequence: "foo\ bar" should be one WORD token with backslash and newline preserved. But for bash and dash , that's not what happens, backslash is not preserved. bash> echo "foo\ > bar" foobar So, I think, <newline> should be removed from the list above (or bash and dash have a bug, or I don't understand something). Issue 3. Now, what about the inclusion of the backslash character itself in the above list in 2.2.3. The meaning of that to me is not well-defined. It would seem in order to decide if the second backlash is special, then again that is what we are deciding about backslashes, so then recursively we would have to look at the character after that, which could also be backslash, and so on. The decision on the first backslash, would depend on the first character (or end of quote) after all the backslashes, and that requires lookahead of more than a small number of characters, which I don't think that is what we want. ------------------------ If we declare that the phrase "when considered special" is wrong and just remove it, that would solve all the issues. Thank you, Mark On Wed, Jan 12, 2022 at 9:51 AM Nick Stoughton <nickstough...@gmail.com> wrote: > > Hi Mark; > please feel free to ask on this list initially. Between us, we should be able > to answer if it is (a), (b), or (c). In general, the POSIX shell was modeled > on ksh88, but a few small changes were incorporated where David Korn (the > author of ksh) said "Oh, that's a bug, I didn't mean it to work that way". > Both bash and dash aim for POSIX conformance in the most part, though > sometimes you have to ask for it explicitly (e.g. "set -o posix" or "bash > --posix" for bash). > > If as a result of discussion on the mailing list we determine that it is (b), > then create a bug on austingroupbugs.net ... if it is (a), then the > maintainers of those shells are generally on this list too, and will take the > appropriate action. > -- > Nick > > On Wed, Jan 12, 2022 at 7:01 AM Mark Galeck via austin-group-l at The Open > Group <austin-group-l@opengroup.org> wrote: >> >> Hello, >> >> a few years ago, I used to report a number of "bugs" on >> www.austingroupbugs.net , however, my reporting was not acted upon, >> which may be because I did not properly understand what you care about >> or not. >> >> So before I do that again, since I don't want to waste anybody's time, >> I want to ask here on the forum, about what kind of reports are >> welcome. >> >> >> I work with your Shell Command Language standard. Sometimes, I read >> some sentence in the standard, I read it carefully, and it seems >> "weird" to me, like, "that is not how the shell is supposed to >> behave". >> >> So I check with bash and dash, and indeed, they do not conform to what >> seems to me the standard is saying. >> >> So then I have a problem - one of several possibilities is true: >> >> a. standard is correct as I read it, that is the way it was intended, >> and bash and dash have a bug >> >> b. standard is not written as intended, standard has a "bug" or at >> least, should be written more clearly, and bash and dash exhibit the >> intended behaviour >> >> c. I am not reading the standard correctly (I have a "bug" in my >> understanding). >> >> >> I care to find out from you which of those are true. >> >> >> Do you care for me to report this kind of thing to austingroupbugs.net >> , or do you not welcome this kind of report? >> >> Thank you, >> >> Mark >>
