[illumos-Developer] [REVIEW] 132 tr breaks scripts

[Richard Lowe]

As noted in bug 132[1], I somehow ended up debugging this, I took the bug,
hopefully with jgrafton's ok.

Assuming so, I'd like review for:
   132 tr breaks scripts

webrev: 
   http://richlowe.net/webrevs/il-tr

As noted in the bug, there're two bugs here, one I guess was discussed
in the earlier thread, is that in inserting parens to gag the compiler a
precedence problem was introduced to cset_in_hard which broke the
character set logic.

The second is that, in bracket(), when parsing a left-hand string
'[=]=]', FreeBSD tr sees '[=]' as a character class, followed by =],
rather than '[=]=]' as an equivalence class.  This can be workaround in
scripts by escaping the centre ']', but it appear that Solaris, xpg4,
and GNU tr all parse such a line.  I've opted to fix this by skipping
the centre character when searching for the = that terminates the
equivalence class.  Care is required here to avoid breaking the
behaviour of '[=*]' on the RHS (I thank the FreeBSD commit logs for
making that plain to me).

I've tested this with the initial example given, with the trtests.sh
script attached to the bug, somewhat by hand, and by running netbeans.

In the case of the cset_in_hard issue, I also compared the dissassembly
of that function both with and without its clarifying parens, and
confirmed that it doesn't change now, though did before.

Ceri, I send-pr'd the brackets() issue[2], but not the precedence one
since I saw some conversation about that in the prior thread (though I
confess, didn't read all of it).  Let me know if yourself and/or Garrett
aren't on top of that.

-- Rich

[1] http://www.illumos.org/issues/132
[2] bin/150384 -- http://www.freebsd.org/cgi/query-pr.cgi?pr=150384