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)
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)
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 >>
Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)
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: when does PATH search stop?
>There is no precise definition of "acceptable" Yes currently there isn't , but it would be easy to make such a definition, simply, for various failure errno numbers (which are enumerated in the standard), say "acceptable", "not acceptable", or perhaps "unspecified".
Re: when does PATH search stop?
Yes, thank you, alternative 3, I was wrong.
when does PATH search stop?
Hello, the shell standard section on Command Search and Execution, says command shall be searched for using the PATH environment variable as described in XBD Environment Variables and that section says the value of PATH is split into a list and "The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found". Well, that is not how both dash and bash behave. They do not search until an exec file with appropriate permissions is found. They stop when a regular file or a symlink is found. Then, if that does not refer to an executable with correct permissions, they do not continue but issue an error. Is the standard wrong, are bash and dash wrong or am I wrong? Thank you, Mark
What does the standard say about whether assignments are visible for subsequent expansions in a simple command without a command name?
Hello, the current shell standard says in Section 2.9.1: --- If no command name results, variable assignments shall affect the current execution environment. If the command name is not a special built-in utility or function, the variable assignments (...) shall not affect the current execution environment (...) In this case it is unspecified: Whether or not the assignments are visible for subsequent expansions in step 4 --- As you can see, if we do have a command, the standard mentions that it is unspecified if the assignments are subsequently visible. So one can say, it is needed to discuss the notion of subsequent visibility. Yet if we don't have a command, the standard does not discuss that at all... One could perhaps interpret that to mean, it is unspecified in that case also. That would mean, there is no need to discuss the notion of subsequent visibility. Thus we apparently have a contradiction - one one hand there is a need to discuss some X, on the other, there is not. As an aside, for dash such assignments are not visible: $ A=; A=a B=$A; echo $B $ but for bash, they are: ~>A=; A=a B=$A; echo $B a ~> Questions: 1. Is that apparent contradiction a bug in the standard that should be fixed, either by adding the visibility clause for both cases, or deleting it for both cases? (in that case, I will make a report). 2. In the larger sense, if the standard does not specify some behaviour that a shell must implement, does that automatically mean it is "unspecified" or "undefined", in the sense of Base Definitions, Section 1.5? 3. In this specific case, is it unspecified what the behaviour is? Or is it specified (which would mean dash or bash have a bug), and what is it? Thank you Mark
another query or, I have been outed as a robot
Hello humans, I had another question about the Shell Standard, but since nobody answered last two, I reckon that the proper thing to do is to log them into "defect tracker". I had previously been reluctant to do so, because if I am not sure something was a defect, why should I log it as such. I am signing up for an account. I have to say, passing the captcha program proved difficult .Yes, I successfully disguised myself as a human for several decades, but now this program finally unmasked me - yes I am indeed a robot... Mark
two things from "Token Recognition" section of the Shell Standard, don't seem to make sense - please comment
Hello, In the Shell Standard (current version 2016), section on Token Recognition, it says (...) shell shall break its input into tokens by applying the first applicable rule below to the next character in its input. and The token shall be from the current position in the input (...) Both of these do not make sense to me. Please comment if you agree or not. 1. "first applicable rule" seems incorrect : if rule 3, 4, or 5 is the first applicable rule, and the current character should be the start of a token, these rules do not say to start a token. In this case we should (I think) follow subsequent rules until we find a rule that says to start a new token. 2. "shall be from the current position in the input" seems to imply, that we start new tokens much too often. If you agree, I can post a bug with a suggested fix. Thank you Mark
Re: how is '(' recognized by the shell standard as a token?
Robert Elz graciously pointed out that 2.9.4 implictly says that ( is in fact
an operator, which solves my problem. Thank you to Robert!
- Original Message -
From: Mark Galeck <mark_gal...@pacbell.net>
To: "austin-group-l@opengroup.org" <austin-group-l@opengroup.org>
Sent: Monday, September 5, 2016 1:52 PM
Subject: how is '(' recognized by the shell standard as a token?
Hello,
when '(' appears in the shell input, how does the section 2.3 Token
Recognition, of the shell standard, recognize it?
'(' can be start of a subshell, or function, or optional start of a `case`
pattern, but nowhere do I see any indication that this is an operator, or
reserved word. Hence it seems to me, that when following section 2.3, no
earlier rule than 9 would apply, so either by rule 9 or 11, '(' is part of a
word.
But that is not how dash behaves:
$ f(
dash: Syntax error: newline unexpected (expecting ")")
$
instead of trying to execute 'f('
So how is '(' recognized?
Thank you,
Mark
dash shell seems to be going both against the POSIX shell standard requirement and approved change to it
Hello,
I thought the dash shell is strictly conforming to the POSIX shell standard.
But it seems, I see a discrepancy. It probably means, I don't understand the
standard. Please explain what is going on.
The standard says in the section 2.2.3 on Double-Quotes and $ : "even number of
unescaped double-quotes or single-quotes, if any, shall occur".
"Shall" means that if that is not followed, an error will result.
There is an approved change to this paragraph, not published yet:
http://austingroupbugs.net/view.php?id=221
which says, instead:
For the four varieties of parameter expansion that provide for
substring processing (see [xref to 2.6.2 Parameter Expansion]),
within the string of characters from an enclosed "${" to the
matching '}', the double-quotes within which the expansion occurs
shall have no effect on the handling of any special characters.
"Shall" means that if that is not followed, an error will result.
But the dash shell does this:
$ FOOBAR="'" ; echo "${FOOBAR#'}"
$
According to the published standard, this should be an error because there is
non-even number of ' inside {}
According to the approved change, there should be no effect of the enclosing ""
on the handling of inside ' , which also does not seem to be the case:
$ FOOBAR="'" ; echo ${FOOBAR#'}
>
I am using the dash from 2011, and the change was approved in Sep 2010.
Thank you for explanation,
Mark
In the POSIX shell standard, why are redirections mixed in with variable assignments and positional parameters?
Hello, the formal POSIX shell grammar for yacc symbol "simple_command" accepts commands which can be loosely summarized as: three parts, each optional, in order: variable assignments and redirections mixed togethercommand namecommand arguments and redirections mixed together It seems to me, the grammar would be simpler and semantics exactly the same, if we moved all redirections to the end (keeping the same order): variable assignmentscommand nameargumentsredirections So, why are redirections mixed in and not moved to the end, which would make everything simpler, and commands easier to understand for a casual user? Is there a situation where doing so would change how the command behaves? I am sorry if I don't see an obvious reason because of my inexperience with the subject matter. Mark
