Re: bug report dispute resolution request

[Ian Jackson <ian@davenant.greenend.org.uk>]

Herbert Xu writes ("Re: bug report dispute resolution request"):
> [SuS has] 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.

I agree completely.  If a shell is required, after seeing $((, to scan
ahead to see whether the thing is supposed to be a command or
arithmetic substitution, then it will have to either read the input
twice, or maintain (and try building) two parse trees.

I think that this is an unreasonable requirement to impose on the
shell.


I see a lot of standards being quoted, and indeed it is usually good
to follow standards - but we shouldn't be afraid to call it a bug for
a program to do something which a standard technically permits but
which is unhelpful or in our view wrong, and also we shouldn't be
afraid to call it a bug in a program if it uses a feature in another
program which is technically required to exist by a standard but which
we feel imposes an undue burden or some such on the other program.

Ie, we should look at standards for guidance, and nearly always for
answers to questions to which there is no `right' answer, but we
should not feel totally bound by them.


Having said that, I think the SuS doesn't completely support Herbert's
view.  Just at the end of the section on command expansion we see:

  If the command substitution consists of a single subshell, such as: 
       $( (command) )
  a portable application must separate the $( and "(" into two tokens
  (that is, separate them with white space).  This is required to
  avoid any ambiguities with arithmetic expansion.

The phrase `single subshell' seems to suggest that it's intended only
to forbid to things like
       $((command | othercommand))
and not
       $((command | othercommand) > file)
       $((command | othercommand) && (command | othercommand))
and the like.  Indeed, only the former is ambiguous when the whole
expression is taken.  This - together with the qualification on the
requirement to use `$( (' instead of `$((', which could have been
unqualified - seems to suggest to me that the SuS intends
the shell to be able to parse any unambiguous expression, even if this
means possible backtracking.


Herbert, is it - in your opinion as ash maintainer, or the opinion of
the upstream authors - a part of the the spec for ash that it is
supposed to support POSIX (let us assume that SuS and POSIX don't
differ on this point) ?


Ian.