Subject: Re: echo semantics (was ksh need help!)
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/20/2001 17:06:04
[ On Thursday, December 20, 2001 at 12:34:35 (-0000), David Laight wrote: ]
> Subject: Re: echo semantics (was ksh need help!)
> There is no 'print' in bourne shell (I've just checked under solaris)
No, and there's not supposed to be, though you can find it in a shell on
That's why Sun supply the XPG4 commands. /usr/xpg4/bin/sh is supposed
to be a POSIX compliant/compatible shell and it does at least have a
(built-in) 'print' command. Note that /usr/xpg4/bin/sh happens to be a
link to ../../bin/ksh, and even though the version of ksh in most
distributions of Solaris I've looked at isn't entirely 100% POSIX
compliant. (If I'm not mistaken the XPG4 specifications became The
Single UNIX Specification (version 1?) in the change-over of X/Open to
The Open Group. XPG4 was a "brand" trademark used to advertise
compliance with X/Open's specifications, and with the coming of SuSv2
the "brand" trademark changes to "UNIX 98")
NetBSD's implementation of echo, at least as far as the /bin/echo and
/bin/sh built-in are concerned, appears to be P1003.2 compliant in every
way, just as echo(1) claims. No doubt the same applies for printf(1).
P1003.2 (at least as of Draft 12, the last publicly available version),
sanely defines a rather more restricted version of 'echo' than SuSv2.
(SuSv2 frequently strays beyond POSIX, often in what appear to be unwise
ways, but that was always the case with X/Open too.)
4.19 echo - Write arguments to standard output
echo [string ...]
The echo utility shall write its arguments to standard output, followed
by a <newline> character. If there are no arguments, only the <newline>
character shall be written.
The echo utility shall not recognize the -- argument in the manner
specified by utility syntax guideline 10 in 2.10.2; -- shall be
recognized as a string operand.
Implementations need not support any options.
The following operands shall be supported by the implementation:
string A string to be written to standard output. If the first
operand is "-n" or if any of the operands contain a
backslash (\) character, the results are implementation
4.19.5 External Influences
188.8.131.52 Standard Input
184.108.40.206 Input Files
220.127.116.11 Environment Variables
The following environment variables shall affect the execution of echo:
LANG This variable shall determine the locale to use for
the locale categories when both LC_ALL and the
corresponding environment variable (beginning with
LC_) do not specify a locale. See 2.6.
LC_ALL This variable shall determine the locale to be used
to override any values for locale categories
specified by the settings of LANG or any
environment variables beginning with LC_.
LC_MESSAGES This variable shall determine the language in which
diagnostic messages should be written.
18.104.22.168 Asynchronous Events
4.19.6 External Effects
22.214.171.124 Standard Output
The echo utility arguments shall be separated by single <space>s and a
<newline> character shall follow the last argument.
126.96.36.199 Standard Error
Used only for diagnostic messages.
188.8.131.52 Output Files
4.19.7 Extended Description
4.19.8 Exit Status
The echo utility shall exit with one of the following values:
0 Successful completion.
>0 An error occurred.
4.19.9 Consequences of Errors
4.19.10 Rationale. (This subclause is not a part of P1003.2)
As specified by this standard, echo writes its arguments in the simplest
of ways. The two different historical versions of echo vary in fatal
The BSD echo checks the first argument for the string "-n", which causes
it to suppress the <newline> character that would otherwise follow the
final argument in the output.
The System V echo does not support any options, but allows escape
sequences within its operands:
\a Write an <alert> character.
\b Write a <backspace> character.
\c Suppress the <newline> character that otherwise follows the
final argument in the output. All characters following the \c
in the arguments are ignored.
\f Write a <form-feed> character.
\n Write a <newline> character.
\r Write a <carriage-return> character.
\t Write a <tab> character.
\v Write a <vertical-tab> character.
\\ Write a backslash character.
Write an 8-bit value that is the 1-, 2-, or 3-digit octal number
It is not possible to use echo portably across these two implementations
unless both -n (as the first argument) and escape sequences are omitted.
The printf utility (see 4.50) can be used to portably emulate any of the
traditional behaviors of the echo utility as follows:
- The System V echo is equivalent to:
printf "%b\n" "$*"
- The BSD echo is equivalent to:
if [ "X$1" = "X-n" ]
printf "%s" "$*"
printf "%s\n" "$*"
The echo utility does not support utility syntax guideline 10 because
existing applications depend on echo to echo all of its arguments, except
for the -n option in the BSD version.
New applications are encouraged to use printf instead of echo. The echo
utility has not been made obsolescent because of its extremely widespread
use in existing applications.
In Draft 8, an attempt was made to merge the extensions of BSD and
System V, supporting both -n and escape sequences. During initial ballot
resolution, a -e option was proposed to enable the escape conventions.
Both attempts failed, as there are historical scripts that would be
broken by any attempt at reconciliation. Therefore, in Draft 9 only the
simplest version of echo is presented. Implementation-defined extensions
on BSD and System V will keep historical applications content. Portable
applications that wish to do prompting without <newline>s or that could
possibly be expecting to echo a "-n", should use the new printf utility
(see 4.50), derived from the Ninth Edition.
The LC_CTYPE variable is not cited because echo, as specified here, does
not need to understand the characters in its arguments. The System V and
BSD implementations might need to be sensitive to it because of their
Copyright c 1991 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
P1003.2/D11.2 INFORMATION TECHNOLOGY--POSIX
P1003.2 obviously also defines printf, and gives the following reason
for doing so:
4.50.10 Rationale. (This subclause is not a part of P1003.2)
The printf utility was added to provide functionality that has
historically been provided by echo. However, due to irreconcilable
differences in the various versions of echo extant, the version in this
standard has few special features, leaving those to this new printf
utility, which is based on one in the Ninth Edition at AT&T Bell Labs.
Also note this from P1003.2:
(6) When irreconcilable differences arose between versions of
historical utilities, new interfaces (utility names or syntax)
were sometimes added in their places. The working group
resisted the urge to deviate significantly from historical
practice; the new interfaces are generally consistent with the
philosophy of historical systems and represent comparable
functionality to the interfaces being replaced. In some cases,
System V and BSD had diverged (such as with echo and sum) so
significantly that no compromises for a common interface were
possible. In these cases, either the divergent features were
omitted or an entirely new command name was selected (such as
with printf and cksum).
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>