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

[Garrett D'Amore]

Looks good, please proceed with integration following the normal
process.

	- Garrett

On Wed, 2010-09-08 at 09:14 -0400, Richard Lowe wrote:
> 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