> Sun is playing this role since years. Go to the shell > and try to > process characters outside the ASCII range with tools > like /usr/bin/tr > or /usr/bin/awk. Even these MAJOR tools are not > capable to process > Chinese or Japanese characters - and Sun refuses to > solve the problem, > citing backwards compatibility as justification. > You can put /usr/xpg4/bin to your PATH variable to > work around the > problem but the system defaults remain in a state > where Sun is playing > the role of a political suicide bomber. > > Irek > _______________________________________________ > i18n-discuss mailing list > i18n-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/i18n-disc > uss >
If it's that important, then perhaps the installer ought to warn of breakage outside the "C" locale and offer to set the default PATH (in /etc/default/init, /etc/default/login, /etc/default/su, and maybe in the files in /etc/skel) to put /usr/xpg4/bin (or whatever is the latest standards-compliant set of directories) ahead of the usual. That would make people aware of the issue early-on, and let them choose at installation time between compatibility and compliance. For that matter, I wonder if such a choice at installation time might not be good even if (as in the "C" locale) choosing compatibility _wouldn't_ cause problems. Insofar as commands supporting both options exist, reminding people at installation time that the responsibility of that choice is theirs (and making it easy to implement by taking care of the details), isn't IMO a bad thing. This message posted from opensolaris.org
