Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes: > > The creation of a binary file from within javacomp.m4 created a wrong file > > on Solaris, because Solaris 'tr' (all of /usr/bin/tr, /usr/xpg4/bin/tr, > > /usr/xpg6/bin/tr) behave differently than GNU 'tr' in a particular case. > > I've tried to read the patch, but it's too much line noise to decipher > quickly. What's the difference in behavior here, and is this something > that we should document in autoconf.texi's portability section?
If I'm reading the patch correctly, the difference shows up in the last hunk of the diff, where Bruno changed ',-.' to ',.', and shuffled all remaining translations by one byte, changing from a translation of 85 distinct bytes to one of 84. But I can't seem to spot the portability problem with -, even when trying: $ echo ',+-/.' | coreutils/tr ',-.' '.,-' .+,/- $ echo ',+-/.' | /usr/bin/tr ',-.' '.,-' .+,/- $ echo ',+-/.' | /usr/xpg4/bin/tr ',-.' '.,-' .+,/- Oh, I finally see it now. There are only 84 bytes being translated; pre-patch, the invocation was "tr [85] [84]", post-patch it is "tr [84] [84]". So the problem was not with '-' (although that can potentially be problematic in its own right), but in the mismatch in charset sizes. And no, I don't see that in the autoconf manual (yet). $ echo 'abc' | coreutils/tr 'bc' 'd' add $ echo 'abc' | /usr/bin/tr 'bc' 'd' adc $ echo 'abc' | /usr/xpg4/bin/tr 'bc' 'd' adc Hmm. It also appears that Solaris /usr/bin/tr handles \0 on output, just not on input; so the autoconf manual needs a tweak anyways. $ printf 'a\0c' | /usr/bin/tr '\0' 'b' | od -tx1 0000000 61 63 0000002 % printf 'abc' | /usr/bin/tr 'b' '\0' | od -tx1 0000000 61 00 63 0000003 I'll see what I can whip up. -- Eric Blake