This discussion is about dead by now, but is it worth pointing out that
csh and sh _both_ use builtin versions of echo?  The sh version supports
\c (and related) options.  (So, for that matter, does BASH; BASH provides
a couple of \-escapes that our sh doesn't, though both seem to provide a
reasonable subset of C string escapes.)

  [Sidenote: sh's manpage does NOT mention that echo is a builtin...yet
   it is builtin.]

With both BASH and our sh, you have to specify ``-e'' to enable the
escapes.  (Though with our sh, a trivial change to make {eflag} a
preprocessor symbol with non-0 value will make ``-e'' unnecessary.)

(Yes, a conscientious script writer will use pathnames for external
programs---but if you know that echo is builtin, why clutter up the
script and lose access to the builtin?)


If NetBSD were a tiny system with few extant scripts, then there would be
very little risk in changing echo, and it would be easy to find/fix the
problems.  As it stands, it seems reckless, to me, to change the standard
echo (either /bin/echo, or the shell builtins).  At present, it is safe to
assume that most (nearly all) scripts in packages or otherwise purportedly
prepared for NetBSD have been correctly modified to work.  If echo is
changed, then you really have no idea which scripts will work as intended.

The functionality is fairly minor, if broken, but surely we have better
things to do than sit down and audit all of our scripts for a marginal
gain?  And, by the same argument of minor impact, imported scripts won't
generally be seriously affected by this.

If any changes were seriously contemplated, would it be best to tie them
to shell variables/environment variables, so that one can selectively get
different behavior?


I'm all for getting rid of silly (void) casts, however.

(ramble)


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com