Re: portability of 'printf' command

[eblake]

On 01/-10/-28163 12:59 PM, Bruno Haible wrote:

> Is the 'printf' command portable enough to be used in configure files
> and autoconf macros?
>
> The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
> when you use bash version 1 (which does not have 'printf' built-in) on a
> platform that does not have a /usr/bin/printf program, you would be hosed.
> But which platforms are this? The Autoconf manual [2] does not mention a lack
> of 'printf' anywhere.
>
> Is someone aware of a platform that does not have a /usr/bin/printf or
> /bin/printf program?

Given that Solaris 8 is about as far back as gnulib currently supports,
I think we are at the point where the known lack of printf(1) in older
Solaris is no longer worth worrying about.  And, given that we document
that awk is safe to use in Makefiles, in spite of its portability
problems, I don't think it is too much of a stretch to support careful
use of printf in portable scripting (the Autoconf manual already does a
good job at documenting considerations to be careful of before using
printf).  So, does this patch seem reasonable?

Index: ChangeLog
===================================================================
RCS file: /sources/gnustandards/gnustandards/ChangeLog,v
retrieving revision 1.108
diff -u -p -r1.108 ChangeLog
--- ChangeLog 28 Mar 2010 00:07:38 -0000 1.108
+++ ChangeLog 5 Apr 2010 19:49:01 -0000
@@ -1,3 +1,7 @@
[phone]  Eric Blake  <eblake@...>
+
+ * make-stds.texi (Utilities in Makefiles): Allow printf.
+
 2010-03-27  Karl Berry  <karl@...>

  * standards.texi (Graphical Interfaces): Recommend D-Bus
@@ -671,7 +675,8 @@
  (Copyright Papers): typo - missing verb.


-Copyright (C) 2004, 2005 Free Software Foundation, Inc.
+Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
+Foundation, Inc.

 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
Index: make-stds.texi
===================================================================
RCS file: /sources/gnustandards/gnustandards/make-stds.texi,v
retrieving revision 1.57
diff -u -p -r1.57 make-stds.texi
--- make-stds.texi 23 Feb 2010 14:13:13 -0000 1.57
+++ make-stds.texi 5 Apr 2010 19:49:01 -0000
@@ -160,7 +160,7 @@ installation should not use any utilitie

 @example
 awk cat cmp cp diff echo egrep expr false grep install-info
-ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch tr true
+ln ls mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true
 @end example

 Compression programs such as @code{gzip} can be used in the


--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[Bob Friesenhahn]

On Mon, 5 Apr 2010, Eric Blake wrote:

> On 01/-10/-28163 12:59 PM, Bruno Haible wrote:
>> Is the 'printf' command portable enough to be used in configure files
>> and autoconf macros?
>>
>> The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
>> when you use bash version 1 (which does not have 'printf' built-in) on a
>> platform that does not have a /usr/bin/printf program, you would be hosed.
>> But which platforms are this? The Autoconf manual [2] does not mention a lack
>> of 'printf' anywhere.
>>
>> Is someone aware of a platform that does not have a /usr/bin/printf or
>> /bin/printf program?
>
> Given that Solaris 8 is about as far back as gnulib currently supports,
> I think we are at the point where the known lack of printf(1) in older
> Solaris is no longer worth worrying about.  And, given that we document

What relevance does gnulib have to Autoconf or printf portability?  It
seems to be irrelevant.

Solaris 8 was released in February 2000.  I still test my own software
on Solaris 2.6 (July, 1997).  Due to hardware support issues, some
people are forced to use an old Solaris version if they still want to
be able to use the hardware.

It is useful that Autoconf (at least) still be prepared to work on
very old bare systems even if many applications don't care to support
old systems.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Dr. David Kirkby]

Eric Blake wrote:

> On 01/-10/-28163 12:59 PM, Bruno Haible wrote:
>> Is the 'printf' command portable enough to be used in configure files
>> and autoconf macros?
>>
>> The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
>> when you use bash version 1 (which does not have 'printf' built-in) on a
>> platform that does not have a /usr/bin/printf program, you would be hosed.
>> But which platforms are this? The Autoconf manual [2] does not mention a lack
>> of 'printf' anywhere.
>>
>> Is someone aware of a platform that does not have a /usr/bin/printf or
>> /bin/printf program?
>
> Given that Solaris 8 is about as far back as gnulib currently supports,
> I think we are at the point where the known lack of printf(1) in older
> Solaris is no longer worth worrying about.  And, given that we document
> that awk is safe to use in Makefiles, in spite of its portability
> problems, I don't think it is too much of a stretch to support careful
> use of printf in portable scripting (the Autoconf manual already does a
> good job at documenting considerations to be careful of before using
> printf).  So, does this patch seem reasonable?

There are quite a few pre Solaris 8 systems around - since Solaris tends to be
used for mission-critical applications, it is often not wise to update them just
because a new release has extra features.

[eblake]

On 04/05/2010 05:42 PM, Dr. David Kirkby wrote:

>>> Is someone aware of a platform that does not have a /usr/bin/printf or
>>> /bin/printf program?
>>
>> Given that Solaris 8 is about as far back as gnulib currently supports,
>> I think we are at the point where the known lack of printf(1) in older
>> Solaris is no longer worth worrying about.  And, given that we document
>> that awk is safe to use in Makefiles, in spite of its portability
>> problems, I don't think it is too much of a stretch to support careful
>> use of printf in portable scripting (the Autoconf manual already does a
>> good job at documenting considerations to be careful of before using
>> printf).  So, does this patch seem reasonable?
>
> There are quite a few pre Solaris 8 systems around - since Solaris tends
> to be used for mission-critical applications, it is often not wise to
> update them just because a new release has extra features.

You missed my point.  Solaris 8 _has_ printf(1) (even though it is not a
shell built-in of /bin/sh, and it can dump core on super-long input), so
the request to add printf as a portable tool does _not_ exclude Solaris
8.  The question at hand is whether it is enough to know how to portably
use printf while avoiding core dumps of less-than-stellar
implementations, and blindly assume that printf(1) exists, or whether we
still need to cater to even older systems (SunOS 4, for example) that
have no printf(1) at all.

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 permitted
tools.

--
Eric Blake   eblake@...    [phone]
Libvirt virtualization library http://libvirt.org

[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 permitted
    tools.

About that, echo -n was and never will be portable, have to go through
the tests of -n vs. \c, etc.  I doubt that's news to anyone here :).

I seem to recall that we've already given up on explicitly testing other
things lacking in SunOS 4, though the specifics elude me.

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.

So I'm not seeing a strong argument against this.  Barring objections,
I'll send it on to rms ... except I'll be offline until next Tuesday, so
don't expect anything before next week.

Thanks,
Karl

[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.

Is it possible that coreutils/sh-utils configure scripts would then
depend on a working 'printf' capability so that it is not possible to
install them?  The only workaround would be to try to bootstrap using
an older version which still does not require 'printf'.

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.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[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 listed in the permitted
>     tools.
>
> About that, echo -n was and never will be portable, have to go through
> the tests of -n vs. \c, etc.  I doubt that's news to anyone here :).
>
> I seem to recall that we've already given up on explicitly testing other
> things lacking in SunOS 4, though the specifics elude me.
>
> 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.
>
> So I'm not seeing a strong argument against this.  Barring objections,
> I'll send it on to rms ... except I'll be offline until next Tuesday, so
> don't expect anything before next week.
>
> Thanks,
> Karl
>

Solaris 7 lacks this, so one does not have to go back as far as you believe.



dave

[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 was not listed in the permitted
>     tools.
>
> About that, echo -n was and never will be portable, have to go through
> the tests of -n vs. \c, etc.  I doubt that's news to anyone here :).
>
> I seem to recall that we've already given up on explicitly testing other
> things lacking in SunOS 4, though the specifics elude me.

Maybe you're remembering free(NULL) ?
It would segfault on SunOS 4, but POSIX now requires it be a no-op.

> 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.
>
> So I'm not seeing a strong argument against this.  Barring objections,
> I'll send it on to rms ... except I'll be offline until next Tuesday, so
> don't expect anything before next week.

[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 therefore will have printf after all.
>
> Is it possible that coreutils/sh-utils configure scripts would then
> depend on a working 'printf' capability so that it is not possible to
> install them?  The only workaround would be to try to bootstrap using
> an older version which still does not require 'printf'.

I think that's an adequate work-around.

[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
presumably wouldn't be happening on mission-critical systems) *and*
(b) have *not* previously installed coreutils/sh-utils?

I suspect the answer is zero.  If it's not zero, then it's at least very
rare, and for those times, it's hardly impossible to get printf one way
or another.  Using bash is another possibility.

I'm still not seeing the problematic scenario here.

Being able to depend on basic printf functionality would be a great boon ...

[Harlan Stenn-7]

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*
> (b) have *not* previously installed coreutils/sh-utils?

I may be missing a key bit here.

The issue is that somebody may be *upgrading* a previously-installed
package.

From my POV, as long as one can bootstrap to the point where there is a
sufficient base of utilities, all is well.

As an aside, I remember there used to be a bunch of GNU utilities that
had not been updated in a Long Time, and it always bothered me that when
new versions of automake/autoconf were available that these other
utilities were not upgraded to use them.

Newer versions of autoconf sometimes fixed bugs and sometimes (better)
detected system vagaries.  They also sometimes made it much easier to
support or allow for things like cross-compiling.

Newer versions of automake sometimes fixed bugs and sometimes added
significant usability items, especially regarding package installation.

If a system is in production, one needs to be able to get new packages
installed on it, and different systems different levels of "bootstrap"
issues will crop up.

I suspect we all know this, but I want to be sure the bootstrap issue is
actively considered in all of this, as it as been my experience all too
often that somebody at point A will make an assumption about the
"foundation" at point B (and perhaps not test it), and then somebody
else will make an assumption at point B about the "foundation" at point
A (and perhaps not test it), and then when reality bites, it is
discovered that with the newer releases of software, "we can't get there
from here".

H

[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.

I still believe this is an epsilon-probability event.  Like most people
here I've updated lots of machines running lots of versions over lots of
years, production and otherwise.  I still cannot fathom a case where
*new* source releases requiring a printf command would be a serious
problem.

k

[Paul Eggert]

"Dr. David Kirkby" <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,
<http://lists.gnu.org/archive/html/autoconf-patches/2006-12/msg00000.html>
and <http://lists.gnu.org/archive/html/autoconf-patches/2006-12/msg00010.html>.

Also, Solaris 7 is pretty far back.  Sun stopped issuing patches for it
in August 2005, and dropped all support in August 2008; see
<http://www.sun.com/service/eosl/solaris/solaris_vintage_eol_5.2005.xml>.
From the GNU project's point of view, there is not a strong argument for
supporting a non-free OS that is not supported by the commercial
supplier itself.

While we're on the subject, Sun stopped issuing patches for Solaris 8 in
April 2009, and will stop supporting it in April 2012.  The
corresponding dates for Solaris 9 are November 2011 and November 2014.
See <http://www.sun.com/software/solaris/releases.jsp>.

[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

[Bob Friesenhahn]

It seems that a conclusion has been reached that it is ok to depend on
printf.  Cheers!

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Karl Berry]

rms said fine to adding printf to the list.  It is committed now.