> 
>   | However NetBSD echo is broken, from the SUS
>   | (http://www.opengroup.org/onlinepubs/007908799/xcu/echo.html):
> 
> echo is a case where being different ("broken") is better.
> If the data is modified, it isn't an echo at all - all that \
> interpretation nonsense was invented by someone who missed the
> existence of a print (or printf) command at shell level, and
> decided echo should be forced into that role.

There is no 'print' in bourne shell (I've just checked under solaris)
> 
> Having echo interpret its args means there's no safe way to
> output the value of a variable (or the output from a command
> or similar) because any of that might have a \ embedded in it.

print -R
> 
> Even the -n arg is a problem there - but at least that one is
> trivial to avoid, just
> 
> echo -n "${var}${nl}"
> 
> where
> nl='
> '

No: because the sus version of echo (and the solaris one) don't
support -n (and none of them support --).

You have to start doing things like [ "`echo -n`" -eq "-n" ]....
> 
> Being compatible with SUS isn't at all important here - everyone
> knows there are 2 different echo behaviours, and deals with that
> (as best they can).  It has been this way for a very long time now.

There are 3 version!
1) raw as in bsd
2) 'normal' (from where I come from) that processes \
3) SVR4 / Unixware which has '-n' and the depracates \c
> 
> And as the SUS says - you should use printf anyway, not echo (they
> don't say why, but it is pretty obviously both because there are
> two quite different echo commands around, and because the one they
> picked to standardise is so obviously brain dead).

Unfortunately the 'printf' they mention isn't a shell builtin.
Using it slugs some scripts well into next week!

    David