mirror/autoconf
2
0
Fork 0
mirror of git://git.sv.gnu.org/autoconf synced 2024-12-09 02:10:22 +08:00
Code Issues Packages Projects Releases Wiki Activity

Clarify comparison of echo, printf, and AS_ECHO*.

Browse Source 
Discussed starting at
<http://lists.gnu.org/archive/html/bug-autoconf/2009-07/msg00025.html>.

* doc/autoconf.texi (Limitations of Builtins): In echo's entry,
give a reason why printf is better than echo.  In printf's
entry, cross-reference echo's entry.
This commit is contained in:
Paolo Bonzini 2009-07-30 20:27:45 +02:00
parent a19e829e67
commit 9b849a97c6
2 changed files with 25 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
ChangeLog
View File

@ -1,3 +1,11 @@
2009-07-30 Paolo Bonzini <bonzini@gnu.org>
Joel E. Denny <jdenny@clemson.edu>
Clarify comparison of echo, printf, and AS_ECHO*.
* doc/autoconf.texi (Limitations of Builtins): In echo's entry,
give a reason why printf is better than echo. In printf's
entry, cross-reference echo's entry.
2009-07-30 Paolo Bonzini <bonzini@gnu.org>
Add back AH_CHECK_HEADERS.

27
doc/autoconf.texi
View File

@ -15826,9 +15826,15 @@ entirely drop the output of the next echo in a command substitution.
Because of these problems, do not pass a string containing arbitrary
characters to @command{echo}. For example, @samp{echo "$foo"} is safe
if you know that @var{foo}'s value cannot contain backslashes and cannot
start with @samp{-}, but otherwise you should use a here-document like
this:
only if you know that @var{foo}'s value cannot contain backslashes and
cannot start with @samp{-}.
If this may not be true, @command{printf} is in general safer and
easier to use than @command{echo} and @command{echo -n}. Thus, scripts
where portability is not a major concern should use @command{printf
'%s\n'} whenever @command{echo} could fail, and similarly use
@command{printf %s} instead of @command{echo -n}. For portable shell
scripts, instead, it is suggested to use a here-document like this:
@example
cat <<EOF
@ -15836,12 +15842,10 @@ $foo
EOF
@end example
New applications which are not aiming at portability should use
@command{printf} instead of @command{echo}. M4sh provides the
@code{AS_ECHO} and @code{AS_ECHO_N} macros, which choose between
@samp{echo -n} on implementations where that works, @command{printf} if
it is available, or other creative tricks in order to work around the
above problems.
Alternatively, M4sh provides @code{AS_ECHO} and @code{AS_ECHO_N} macros
which choose between various portable implementations: @samp{echo}
or @samp{print} where they work, @command{printf} if it is available,
or else other creative tricks in order to work around the above problems.
@item @command{eval}
@ -16143,11 +16147,14 @@ example, @file{/usr/bin/printf} is buggy, so when using
core.
Since @command{printf} is not always a shell builtin, there is a
potential speed penalty for using @code{printf %s\\n} as a replacement
potential speed penalty for using @code{printf '%s\n'} as a replacement
for an @command{echo} that does not interpret @samp{\} or leading
@samp{-}. With Solaris @command{ksh}, it is possible to use @code{print
-r --} for this role instead.
For a discussion of portable alternatives to both @command{printf}
and @command{echo}, @xref{echo, , Limitations of Shell Builtins}.
@item @command{pwd}
@c ----------------