A couple weeks or so ago I posted four versions of echo.c=20
from open source operating systems and asked which one=20
was best; a few people peeked at CVS themselves and
know which verion is netBSD but still wanted to know where
the other versions came from-- so here's the answer.

(The thread began in port-i386 so I'll end it there, any followups
should go to current-users.)

I expected the thread to digress into "but how do you
just echo '-n'??" but recognize that this isn't very important.
The points I was trying to make in posting the source=20
(none of which are unique to echo.c-- it was just a simple
example) were:


 - I thought they would be more alike.  The benefit of open
source is to be able to borrow the best features from others,
right?  So I was surprised they were not all the same (we're
talking about echo, here-- not kernel rocket science.)

- A few differences are probably due to the build process=20
(lint, etc), except for the '\c' compatibility, which only one=20
version supports.  WHY?  In the late 80s when I became=20
familiar with *ix, none of the gurus could agree on the what,=20
where, why, how  of compatiblity; that's understandable,=20
because there wasn't much source back then and there
were other (bigger) issues to worry about.  I had thought
this problem would be solved by now-- we have the source
and we control the build-- so it's easy to create compatibility=20
in small utilities like this one, yet only one bsd out of three=20
allowed SYSV scripts to not bug.  ("Why bother?" several
people asked.  It's important for the simple reason that there
are gigabytes of scripts in archives out there and it takes
very little effort (in this case anyway) to allow them to all run=20
flawlessly.  This is the legacy problem and it will not go away,=20
especially with open source now popular-- source code lasts=20
*forever*!  So it should work ten years from now, right?)

- It is interesting that they all have the same comment:
	/* This utility may NOT do getopt(3) option parsing. */
with improper use of "may" (probably should say "must" or
"might") and no explaination why.  Does anyone else find it=20
interesting that comments often hang around code without
verification while the source is picked apart and reviewed?
Obviously, using getopt() would be overkill for one-option
checking here.

Note that SYSV compatibility allows use of:
      echo Yes or No? \c=20
which will not output newline.  In BSD, this must be:
      echo -n Yes or No?

So anyway..


A: FreeBSD.  Supported '\c' for SYSV compatibility, but it
checked for '\c' by byte comparison and not 'strcmp', which
I find inconsistent.  Performs 'while(argv[0])' which a couple
people found annoying; 'while(*argv)' might be more intuitive.
Uses printf(), which I think is a waste of processing.  Had=20
inconsistent and useless (void)s for return values.  Uses=20
exit(0) which is good.

B: NetBSD.  The cleanest, since it has /* NOTREACHED */ :-). =20
Consistent use of (void) but uses printf() which is wasteful.
No SYSV compatibility.  Uses exit(0) which is good.

C: My own mutation.  Specifically sets the flag at the beginning,
which is the proper thing, IMHO.  Checked for '-n' by byte=20
comparison, which many people found annoying and hard to=20
read; I agree, strcmp is better.  No SYSV compatibility.

D:  OpenBSD.  This one is by far the most secure.  (Just kidding!) =20
It uses return(0), when exit(0) would be the proper thing.
Uses fputs(), which is good.  Should use fputchar() instead of=20
putchar() in order to be consistent.  No SYSV compatibility.
It should be noted at in a secure environment, a script will most
likely run /bin/echo instead of relying on the shell to resolve
"echo".

E: There was no 'E'.  I wanted to post a linux version, but=20
haven't found anything like CVSweb on their sites.

This discussion is not limited to 'echo', remember.  I've been
surfing around CVSweb (incredible system!  I never would=20
have imagined such a thing back when I was hacking SYSV=20
many ago) and the differences between the BSDs was subtle=20
but striking.  Might it not be better to develop a build tool which=20
performs automated diffs of other open source systems?
Imagine how fast BSD could borrow the good things from Linux=20
(which, since it is becoming more mainstream every day, will be=20
getting a broader development base) if such a thing existed..
Or how fast security holes in NetBSD might be plugged after they
were patched in OpenBSD..  The idea is to rapidly implement the
improvements from one open source operating systems into
others.


That's my code review for the day..

Does anyone remember where this quote came from?=20
 "I don't know what OS will be running in the future,
  but it will be call Unix."