Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
OK I understand, that's what I was worried about, some kind of issue like that. I don't expect any such thing come up from a customer really, it's unlikely. If it does and the fix is not yet officially published, well I will handle it without pasting or referring to the draft. Sorry and thank you. On Fri, Jan 14, 2022 at 6:57 AM Andrew Josey wrote: > > Hello Mark > > Thanks for your mail. There are various restrictions on the unapproved > drafts imposed > on us by the standards process and the copyright holders, including various > disclaimers and notices of limitations we have to place in the drafts. > > In short the drafts are only intended to be used for standardisation > activities without > permissions from the copyright holders, they are unapproved and subject to > change. > It is not intended that the drafts be passed to end user customers. > > Since all changes in the drafts relate to bugs, that would be a possible > route if you needed to point > to a change proposed, as we discuss and record all changes via the mantis bug > tracker > and that information is public. In the CHANGE HISTORY section of the draft we > record the defect number so > that is a way for you to vector in on the information. Note for numbered > sections rather than manual > pages you would need to consult the XRAT volume to find out the defects > applied - for example > XRAT C.2.2.3 notes a number of defect reports applied. > > I hope this helps. > regards > Andrew > > > On 13 Jan 2022, at 13:02, Mark Galeck via austin-group-l at The Open Group > > wrote: > > > > Yes thank you, this is very helpful. > > > > Right now, I point the customers to the current published POSIX > > standard, when it comes to behaviour that is covered there. > > > > However, if they do raise an issue like this, that is already > > addressed in the draft, I would want to copy-and-paste a section from > > the draft, to an email to the customer that raised the issue, with an > > explanation that this is what the intent is . > > > > I would rather not point to or provide the whole draft, for fear of > > confusion. > > > > > > Is that OK for me to do that? > > > > On Thu, Jan 13, 2022 at 3:36 AM Geoff Clare via austin-group-l at The > > Open Group wrote: > >> > >> Mark Galeck wrote, on 13 Jan 2022: > >>> > >>> Thank you Nick. So here's the one I just found. > >>> > >>> In the section 2.2.3 Double-Quotes, it says about \ : > >>> > >>> "The 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: > >>> > >>> $ ` " \ > >>> " > >> > >> I believe the issues you raise with this text have been corrected > >> already in the Issue 8 drafts. You should be able to obtain the > >> current draft from https://www.opengroup.org/austin/login.html > >> > >> -- > >> Geoff Clare > >> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England > >> > > > > > Andrew JoseyThe Open Group > Austin Group Chair > Email: a.jo...@opengroup.org > Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England > > To learn how we maintain your privacy, please review The Open Group Privacy > Statement at http://www.opengroup.org/privacy. > To unsubscribe/opt-out from this mailing list login to The Open Group > collaboration portal at > https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481 > > > >
Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
Hello Mark Thanks for your mail. There are various restrictions on the unapproved drafts imposed on us by the standards process and the copyright holders, including various disclaimers and notices of limitations we have to place in the drafts. In short the drafts are only intended to be used for standardisation activities without permissions from the copyright holders, they are unapproved and subject to change. It is not intended that the drafts be passed to end user customers. Since all changes in the drafts relate to bugs, that would be a possible route if you needed to point to a change proposed, as we discuss and record all changes via the mantis bug tracker and that information is public. In the CHANGE HISTORY section of the draft we record the defect number so that is a way for you to vector in on the information. Note for numbered sections rather than manual pages you would need to consult the XRAT volume to find out the defects applied - for example XRAT C.2.2.3 notes a number of defect reports applied. I hope this helps. regards Andrew > On 13 Jan 2022, at 13:02, Mark Galeck via austin-group-l at The Open Group > wrote: > > Yes thank you, this is very helpful. > > Right now, I point the customers to the current published POSIX > standard, when it comes to behaviour that is covered there. > > However, if they do raise an issue like this, that is already > addressed in the draft, I would want to copy-and-paste a section from > the draft, to an email to the customer that raised the issue, with an > explanation that this is what the intent is . > > I would rather not point to or provide the whole draft, for fear of confusion. > > > Is that OK for me to do that? > > On Thu, Jan 13, 2022 at 3:36 AM Geoff Clare via austin-group-l at The > Open Group wrote: >> >> Mark Galeck wrote, on 13 Jan 2022: >>> >>> Thank you Nick. So here's the one I just found. >>> >>> In the section 2.2.3 Double-Quotes, it says about \ : >>> >>> "The 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: >>> >>> $ ` " \ >>> " >> >> I believe the issues you raise with this text have been corrected >> already in the Issue 8 drafts. You should be able to obtain the >> current draft from https://www.opengroup.org/austin/login.html >> >> -- >> Geoff Clare >> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England >> > Andrew JoseyThe Open Group Austin Group Chair Email: a.jo...@opengroup.org Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England To learn how we maintain your privacy, please review The Open Group Privacy Statement at http://www.opengroup.org/privacy. To unsubscribe/opt-out from this mailing list login to The Open Group collaboration portal at https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481
Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
Yes thank you, this is very helpful. Right now, I point the customers to the current published POSIX standard, when it comes to behaviour that is covered there. However, if they do raise an issue like this, that is already addressed in the draft, I would want to copy-and-paste a section from the draft, to an email to the customer that raised the issue, with an explanation that this is what the intent is . I would rather not point to or provide the whole draft, for fear of confusion. Is that OK for me to do that? On Thu, Jan 13, 2022 at 3:36 AM Geoff Clare via austin-group-l at The Open Group wrote: > > Mark Galeck wrote, on 13 Jan 2022: > > > > Thank you Nick. So here's the one I just found. > > > > In the section 2.2.3 Double-Quotes, it says about \ : > > > > "The 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: > > > > $ ` " \ > > " > > I believe the issues you raise with this text have been corrected > already in the Issue 8 drafts. You should be able to obtain the > current draft from https://www.opengroup.org/austin/login.html > > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England >
Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
Mark Galeck wrote, on 13 Jan 2022: > > Thank you Nick. So here's the one I just found. > > In the section 2.2.3 Double-Quotes, it says about \ : > > "The 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: > > $ ` " \ > " I believe the issues you raise with this text have been corrected already in the Issue 8 drafts. You should be able to obtain the current draft from https://www.opengroup.org/austin/login.html -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
Thank you Nick. So here's the one I just found. In the section 2.2.3 Double-Quotes, it says about \ : "The 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: $ ` " \ " 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 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, 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 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 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 >>
Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
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 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 > >
