Re: Issue with AS_TR_CPP, m4_cr_all and EBCDIC codeset

2010-04-07 Thread Eric Blake
On 04/06/2010 11:02 PM, Ralf Wildenhues wrote: > Hello, > > * Eric Blake wrote on Sat, Apr 03, 2010 at 01:32:45AM CEST: >> +Fix m4_cr_all for EBCDIC. >> +* lib/m4sugar/m4sugar.m4 (m4_cr_all): Swap * and $, so that we >> +don't end up with $* in EBCDIC. >> +Reported by Steve Goetze.

Re: portability of 'printf' command

2010-04-07 Thread Karl Berry
And the reason that I would _like_ to have printf(1) added to the list of portable tools is because of the number of non-portable shell scripts that are currently using 'echo -n', which is doomed to failure in some shells, instead of printf because printf was not listed in the permi

Re: portability of 'printf' command

2010-04-07 Thread Bob Friesenhahn
On Wed, 7 Apr 2010, Karl Berry wrote: In any event, I suspect that anyone using such an ancient system *and* installing a brand-new version of package foo that uses printf in its autoconfery would also have installed coreutils (or at least sh-utils), and therefore will have printf after all. I

Re: portability of 'printf' command

2010-04-07 Thread Dr. David Kirkby
Karl Berry wrote: And the reason that I would _like_ to have printf(1) added to the list of portable tools is because of the number of non-portable shell scripts that are currently using 'echo -n', which is doomed to failure in some shells, instead of printf because printf was not

Re: portability of 'printf' command

2010-04-07 Thread Jim Meyering
Karl Berry wrote: > And the reason that I would _like_ to have printf(1) added to the list > of portable tools is because of the number of non-portable shell scripts > that are currently using 'echo -n', which is doomed to failure in some > shells, instead of printf because printf w

Re: portability of 'printf' command

2010-04-07 Thread Jim Meyering
Bob Friesenhahn wrote: > On Wed, 7 Apr 2010, Karl Berry wrote: >> >> In any event, I suspect that anyone using such an ancient system *and* >> installing a brand-new version of package foo that uses printf in its >> autoconfery would also have installed coreutils (or at least sh-utils), >> and ther

Re: portability of 'printf' command

2010-04-07 Thread Karl Berry
Solaris 7 lacks this, so one does not have to go back as far as you believe. I fully recognize that people are still running Solaris 7 (and probably older versions) on mission-critical and other systems. But, how many of those systems are (a) installing brand-new GNU packages (which presu

Re: portability of 'printf' command

2010-04-07 Thread Karl Berry
Hi Harlan, >From my POV, as long as one can bootstrap to the point where there is a sufficient base of utilities, all is well. I agree. "we can't get there from here". As has been said: install (say) coreutils-8.4, which does not require printf. This gives you printf. Then proceed

Re: portability of 'printf' command

2010-04-07 Thread Paul Eggert
"Dr. David Kirkby" writes: > Solaris 7 lacks this, so one does not have to go back as far as you believe. No, Solaris 7 has /usr/bin/printf. If memory serves, it also has a /bin/ksh that supports printf. See, for example,

Re: portability of 'printf' command

2010-04-07 Thread Bruno Haible
Bob Friesenhahn wrote: > The versions of SunOS which were implied to be too old to support were > versions prior to Solaris 8 (SunOS 5.8), rather than SunOS 4. Solaris 5.6 (released in 1997) also already had /usr/bin/printf. Bruno ___ Autoconf mailin

Re: portability of 'printf' command

2010-04-07 Thread Bob Friesenhahn
It seems that a conclusion has been reached that it is ok to depend on printf. Cheers! Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___

Re: portability of 'printf' command

2010-04-07 Thread Harlan Stenn
Karl wrote: > I fully recognize that people are still running Solaris 7 (and probably > older versions) on mission-critical and other systems. But, how many of > those systems are (a) installing brand-new GNU packages (which > presumably wouldn't be happening on mission-critical systems) *and* >