Re: [PATCH] latest ash has broken 'echo' command
> On Mon, Oct 25, 1999 at 11:44:38AM +0200, Marek Habersack wrote:
> >
> > You keep repeating this argument, but so far you haven't presented us the
> > relevant fragment of the standard that specifically forbids the behavior.
>
> OK, this is the last time that I'll spell it out to you. I'm in this debate
> because I maintain a package called ash. That package exists for the sole
> purpose of acting as /bin/sh. That is only possible if all #!/bin/sh scripts
> were restricted by some standard. This currently happens to be POSIX.
I think that some of us see your point, and your argument, but just
don't agree with it.
Let me state what I think the facts are that we can all agree on:
\beginfacts
F1. POSIX defines the use of the "-n" flag to echo(1) as an optional
feature for suppressing the terminating newline at the of the echo(1)ed
string.
F2. Because "echo -n" is optional, portable #!/bin/sh scripts cannot
rely on its existance for proper operation. POSIX recommends printf(1)
as an alternative that is more flexible than "echo".
F3. Currently, most Debian echo(1) commands, including /bin/echo, shell
builtins for bash and ksh, and probably others, support "echo -n".
[Ash is the only exception I know of.]
F4. Several installed scripts in Debian that specify #!/bin/sh use the
"echo -n" construct.
F5. Bash supports several features, colloquially known as "bashisms"
that are neither required nor specified as optional in POSIX. It is
currently against Debian policy for installed scripts that specify
#!/bin/sh to use bashisms. Bashisms are allowed if #!/bin/bash is
specified.
Please note that I am not including POSIX-optional features in my
definition of "bashisms". If F1 is true, then by my definition, "echo
-n" is -not- a bashism.
\endfacts
What I don't know, what I have questions about, include:
\beginquestions
Q1. Does the relevant POSIX document include echo(1) as part of the
shell, or does it assume that it is discussing /bin/echo, or is it
neutral on the matter (e.g., does it discuss an "environment", which
includes echo(1), but doesn't bias towards any particular
implementation).
Q1a. If it assuming /bin/echo, and shells implement it as a builtin for
convenience and speed, shouldn't the shells try to match the behavior
of the existing /bin/echo?
Q1b. Can ash completely remove support for echo(1) as a shell builtin
without violating policy or POSIX? That would mean that echo(1) would
be provided by /bin/echo when running ash.
Q2. Can a POSIX-compliant #!/bin/sh script use optional POSIX features
(like "echo -n") in environments where they are known to exist?
Granted, such a POSIX-compliant script won't be -portable-.
\endquestions
My personal opinion is that the answer to 2 is yes, and that based on
F3, Debian would qualify as an environment where the optional POSIX
feature of "echo -n" is known to exist. Removing support for "echo -n"
is going contrary to established practice in Debian, and is not
required by POSIX.
Explicitly specifying that "echo -n" is known to exist in policy may be
a good idea.
--
Buddha Buck bmbuck@zaphod.dhis.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Reply to: