Re: [PATCH] latest ash has broken 'echo' command

[Roland Rosenfeld <roland@spinnaker.de>]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Before ash appeared, Debian/GNU Linux supported stuff like the
> function keyword, {} substitution, and a host of other things. That
> certainly did not give me any impetus to do those things in ash. Why
> should this be any different?

I agree with you in the question of "echo -e", but I still have a
problem with "echo -n".  We need some way to output a line without a
trailing linefeed from a /bin/sh script.  So the question is, _how_
this way should look like.  Have a look at our policy, which
explicitly proposes to use "echo -n" in many examples like this:

  echo -n "Starting domain name service: named"
  start-stop-daemon --start --quiet --exec /usr/sbin/named
  echo "."

So how should this be implemented, if /bin/sh doesn't support "echo -n"?
If I didn't miss something, the POSIX replacement for the above is

  echo "Starting domain name service: named\c"

This is a nice idea, but it is neither supported by bash nor by the
old ash behavior, so using "echo \c" will cause many problems with
different shells.  So what alternative do you see here?  You compared
this problem with function keyword and {} substitution.  These can
both be simple replaced by portable alternatives (remove the function
and replace {} by the explicit file names).  But how do we substitute
"echo -n" in a portable way?

The only portable solution is a little function like this

echon () {
   if [ -z "`echo -n`" ]; then
       echo -n "$*"
   else
       echo "$*\c"
   fi
}    

(hoping that every shell, which doesn't support "echo -n", supports
"\c", or alternatively add en elsif, which does and additional test
and falls back to printf(1)).

Do you really want such a portability workaround in _every_
/etc/init.d script and in many other scripts?  Don't forget, that this
may slow down scripts even more...

You told us to always use printf(1) as an alternative, but is this an
acceptable alternative?  Can we be sure, that printf(1) is always
available (at the moment it located in /usr/bin, which makes it
unusable for init.d scripts, which should also work when /usr is not
mounted)? And don't forget, that printf(1) is implemented as an
external program, while echo is a built in with most shells, which
means a difference in performance and it may be safer in some
situations, if some scripts use only internal programs instead of
forking (think about a situation with a filled process table, where a
script like /etc/init.d/rc should work without forking, if possible).

Simply saying, that we won't support "echo -e" any longer isn't
acceptable for me, you have to give an acceptable alternative.  I just
get rid of most "echo -n" and all "echo -e" uses in the file-rc
scripts and I think, we should try to do so in every /bin/sh script,
but there is still one "echo -n" kept, because I want to output a dot
every two seconds while waiting for a lock to disappear. But until I
see an acceptable alternative to "echo -n" in this, it will stay
there. So tell me how to solve this problem...

And keep in mind, that all(?) sh compatible shells on a Debian system
(ash, bash, pdksh, zsh) as well as /bin/echo from shellutils support
"echo -n", while echo \c (without "-e") isn't supported by /bin/echo,
ash and bash.  So "echo -n" seems to be the most portable way here
(keeping in mind that POSIX allows a shell to support this).

Tschoeeee

        Roland

-- 
 * roland@spinnaker.de * http://www.spinnaker.de/ *