Some older shells don't do longest match tokenizing of operators, so they
might construe
++a as +(+a) or --a as -(-a). I suspect that is how dash and ksh88 are
actually evaluating
them, not ignoring them silently. With some hardware -(-a) isn't a no-op;
it forces a format
normalization. The current rules embody longest match for newer shells, so
they can add
those operators, and comma for that matter, as extensions. FreeBSD uses
longest match,
it looks, but chooses not to implement the operators so treats them as an
error. Shells
operating in conforming mode should be reporting it also, at least as a
warning. The
restriction is so conforming scripts that don't use the operators will
continue to work as
expected on systems still using one of those older shells for sh. When
limited to the base
operators the older ones are still nominally conforming, iow.
In a message dated 3/18/2017 1:35:07 P.M. Eastern Daylight Time,
mart...@inlv.org writes:
(0003623) stephane (reporter) - 2017-03-17 10:32
http://austingroupbugs.net/view.php?id=1128#c3623
> That's for instance why the spec says it's unspecified (or implementation
> defined, I don't remember) whether ++ and -- are supported or not, to
tell
> applications not to assume $((--a)) is the same as $((- - a)) (as they
> could if they had left that bit out).
The exact wording is that these are "not required" to be supported.
Speaking of which, I don't understand why this is. The
{pre,post}-{in,de}crement operators are a very frequently used feature
of C-style arithmetics, so users expect them. Implementing these surely
is rather trivial.
So it seems like an unnecessary annoyance that you cannot rely on these
in a cross-platform shell script -- particularly since (as Stéphane
points out above) this creates an avoidable ambiguity: $((--a)) and
$((++a)) do not have the same meaning on every shell.
Are there any reasons for that decision, other than "ksh88 didn't
support them", that I may not be aware of?
If ksh88 is the reason, then maybe it's time to revisit this.
The only current POSIX shells I'm aware of that *don't* support them are
Almquist derivatives dash and FreeBSD sh[*]; even Busybox ash added them
(as did ksh88 clone pdksh, back in 1993).
(Dash silently accepts $((--a)) and $((++a)) as equivalent to $((a)), as
did ksh88; FreeBSD sh rejects them.)
- M.
[*] as well as another Almquist derivative, NetBSD sh, but it is far too
obsolete to be considered POSIX in 2017.
