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

Re: bug report dispute resolution request



On Tue, Dec 12, 2000 at 06:04:09PM -0500, Branden Robinson wrote:
> 
> I said:
> 
> > The parser is too hasty. $(( only means "go into arithmetic mode" if it's
> > matched by a "))".

There's something wrong with your mail setup.  I never got that message.
Not that it makes any difference to my decision though.

> Herbert says:
> 
> > I do not see anything in the standards that requires this text to be parsed
> > in the way you intend it to be.  Thus for your script to be
> > POSIX-compliant, you must insert at least one white space between $( and (
> > to disambiguate it.
> 
> Herbert does not quote the standards in question, so it is difficult for me
> to evaluate his assertions.  Bash does the right thing with the cited

Here is what the SuS says (AFAIK POSIX says the same thing):

Token Recognition

...

         5.If the current character is an unquoted "$" or `, the shell
         will identify the start of any candidates for parameter expansion,
         command substitution, or arithmetic expansion from their
         introductory unquoted character sequences: "$" or ${, $( or
         `, and $((, respectively. The shell will read sufficient input
         to determine the end of the unit to be expanded (as explained
         in the cited sections).  While processing the characters, if
         instances of expansions or quoting are found nested within the
         substitution, the shell will recursively process them in the
         manner specified for the construct that is found. The characters
         found from the beginning of the substitution to its end, allowing
         for any recursion necessary to recognise embedded constructs,
         will be included unmodified in the result token, including any
         embedded or enclosing substitution operators or quotes. The
         token will not be delimited by the end of the substitution.

There is nothing about backtracking when parsing a $(( expression if the
terminating )) is not found.  Indeed, such expressions would be slow to
parse anyway and should be avoided if the underlying shell supports it.

> construction, and POSIX arithmetic is not a bashism, therefore bash's
> behavior likely doesn't violate the standard either, by doing what it does.

Indeed it doesn't.  But that doesn't mean portable scripts should rely on
this behaviour.

> Had Herbert bothered to pay any attention at all, he'd have noticed that I
> already introduced the suggested workaround in xserver-xfree86.config to
> work with existing versions of ash.

Well, since IMHO the bug in question wasn't a bug (against ash) at all,
without any info as to whether you've taken any actions on your part, I
felt that the best course of action was to reassign it back to you and
have you decide whether to fix it/close it/or do something else completely
different.

Incidentally, I just checked auric and cannot find a fixed version either
in the archive (the latest being the version that the bug was filed against)
or in Incoming.

> However, the issue of how ash parses POSIX shell syntax is tautologically
> ash's issue.  Depending on what the POSIX specification says, Herbert may
> be able to justify downgrading this bug report to a wishlist item (which,

I disagree.  Since this behaviour is legal and IMHO the only sensible one,
there is no bug in ash at all.  Bash's implementation is perfectly legitimate
as well, but that has no bearing on how ash should chose to implement it.

> given his attitude, would indicate that he has no intention of ever

I think that if you looked at my archived bugs, you would find that the
most of the wishlist bugs have been fixed.

> addressing it), but reassigning it to xserver-xfree86 is nonsensical.

That's where we disagree.

> I request that the technical committee rule on this issue to reverse
> Herbert's action of assigning bug reports that belong with his package to
> inappropriate and irrelevant packages instead.

My opinion is that since the bug was a result of an undefined expression
in xserver-xfree86, it made sense to reassign it to the offending package,
regardless of whether the bug has actually been fixed there or not.  In
any case, it hasn't been fixed in xserver-xfree86 (at least not in our
archives or Incoming, AFAIK) yet.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



Reply to: