Unix V5, OpenBSD, Plan 9, FreeBSD, and GNU implementations of echo.c

https://gist.github.com/1091803

by dchest • 15 years ago

168 86 15 years ago

gist.github.com

IvarTJ• 15 years ago

That must have been one of Ken Thompson’s more productive days.

(alluding to a quote from him that I can’t source, “One of my most productive days was throwing away 1000 lines of code.”)

silentbicycle• 15 years ago

Nah, the codebase just hadn't been touched by the FSF yet.

See also, "UNIX Style, or cat -v Considered Harmful" (http://harmful.cat-v.org/cat-v/).

It seems telling that the GNU echo's source is "derived from code echo.c in Bash."

andrewcooke• 15 years ago

i don't get while people are being snide about code that does more and so has more lines. a small amount of code is very nice and elegant, but if it doesn't do what people need then it's pointless.

nvictor• 15 years ago

wow :O

scythe2• 15 years ago

Okay, so... from UNIX v5, OpenBSD added a -n flag that prevents a trailing newline, Plan 9 adds the -n flag and pushes the argv into a buffer (why?) before printing, FreeBSD does all that and also prevents a trailing newline if the last argument ends with "\c" (why?), and GNU does... something complicated.

mikelward6• 15 years ago

"adds the argv into a buffer (why?)"

It's calling "write", which is a system call. Without the buffer, it would call write once for argv, and once for the newline if nflag is not set. Calling a system call twice would result in twice as many context switches, and thus be very slightly slower.

scythe2• 15 years ago

Oh, that makes sense.

Speaking of clever tricks, would it be faster or slower to use c99's variable-length arrays instead of malloc?

haberman2• 15 years ago

Isn't that what stdio is for (fopen()/fread()/fwrite()/etc)? It performs buffering for you.

Someone• 15 years ago

If speed is important, why the copying of the data? Only 'slightly' non-portable:

  int main (int argc, const char * argv[])
  {
    for( int i = 1; i < argc; ++i)
    {
        ((char *)argv[i])[-1] = ' ';
    }
    size_t len = strlen(argv[argc - 1]);
    ((char *)argv[argc - 1])[len] = '\n';
    write(1, argv[1], argv[argc - 1] - argv[1] + len + 1);
    return EXIT_SUCCESS;
  }

ori_b• 15 years ago

It has to do with the way plan9 guarantees atomic writes of small buffers. A single write() call will correspond to a single read() call if the buffer is big enough to receive it.

Wilya• 15 years ago

Actually, most of what the GNU is doing is recognising some escape sequences (including characters in hex form).

dchest2• 15 years ago

It seems like "-n" flag appeared in UNIX v7: http://www.bsdlover.cn/study/UnixTree/V7/usr/src/cmd/echo.c....

enneff• 15 years ago

Plan 9's echo is used to talk to drivers from shell scripts, some of which expect to receive messages in a single buffer. That's why they went out of their way to make echo use a single write.

chaosfox• 15 years ago

slightly related but, I also find it funny that most of the time we are running none of these..

  $type echo
  echo is a shell builtin

pixelbeat• 15 years ago

One should avoid echo anyway due to portability issues. Use printf instead.

robtoo• 15 years ago

More *nix systems have a /bin/echo than /bin/printf or /usr/bin/printf

mikelward6• 15 years ago

Yes, and they all do something dfferent. Things like "-e" and treatment of "\c" are not uniform.

If a system has printf, and I think all recent Unix-like systems do, then it works at least 98% the same.

mikelward6• 15 years ago

The "-n" option was added to UNIX around v6.

The "-n" special case opened the floodgates for many more options. And what if I actually wanted to print "-n"? There's no way to do it.

ilikejam3• 15 years ago

Sure you can:

dave@cronus $ ./echo -n "-n

dave@cronus > "

-n

dave@cronus $

Not pretty, though.

mikelward6• 15 years ago

You're right. I should have said "no sane way to do it". :-)

martinp• 15 years ago

Or echo -en "-n\n".

mturmon2• 15 years ago

Cute, but does not work with bash builtin echo, for which two -n's equals one -n.

   bash-3.2$ echo -n -n foo
   foobash-3.2$

Like always with echo -n, no matter what you try, it's not portable.

bch2• 15 years ago

> And what if I actually wanted to print "-n"? There's no way to do it.

Good point.I first tried "echo \-n", and "echo -- -n". No luck. I get the correct visual effect with "echo - ^Hn" (^H generated with ^V, backspace), but the embedded backspace is still actually part of the output :P "echo - ^Hn | col" strips it. Seems like quite an oversight, really, and is prime example of how bugs sneak into code via features.

edit: ilikejam solved it w/o leaning on other tool. As he said "not pretty", but simpler than what I have: http://news.ycombinator.com/item?id=2781034

pyre3• 15 years ago

Use the source... ;-)

  % env POSIXLY_CORRECT=1 echo -n  
  -n

Also note that if your shell is Bash, then your echo is a built-in:

  % type echo
  echo is a shell builtin

That's why 'env' is necessary.

AlecSchueler• 15 years ago

`echo -e -\\x6E` works in GNU echo and Bash builtin (and likely others).

bdonlan3• 15 years ago

The printf utility works far better if you want detailed control of your output: printf "%s\n" -n

mikelward6• 15 years ago

You can see the original UNIX sources at http://minnie.tuhs.org/cgi-bin/utree.pl

hackermom2• 15 years ago

Following the general software trend, it just keeps growing bigger and slower while still doing nothing new. But is this used anywhere, really? At least Bash uses its builtin.

p9idf7• 15 years ago

Bash's implementation[1] isn't especially fast. It gets its speed by not having to fork, which is expensive on systems with dynamic linking.

[1] http://git.savannah.gnu.org/cgit/bash.git/plain/builtins/ech... http://git.savannah.gnu.org/cgit/bash.git/plain/support/rech... http://git.savannah.gnu.org/cgit/bash.git/plain/support/zech...

pyre3• 15 years ago

  > while still doing nothing new

Really? So the GNU implementation is an exact match for the functionality of the SysV implementation? If so, I have a bridge I'd like to sell you...

brown9-2• 15 years ago

I do not have much experience reading C code. Is the use of gotos and labels in the GNU code common?

Peaker3• 15 years ago

For error handling it is considered fine.

The way it is used in that code is pretty horrible, IMO, and splitting it into functions and using "return" in place of goto would have been far better.

sjs2• 15 years ago

In C it's generally accepted that forward jumps using goto are okay because the version that avoids goto would be complicated and confusing. Often used for error handling and memory management.

sliverstorm2• 15 years ago

Error handling because you want to make a beeline to the handler, and memory management because you need it to be quick and goto is cheap?

Peaker3• 15 years ago

Can you explain what you mean by use of gotos for memory management?

hackermom2• 15 years ago

A somewhat related by-the-way: if you grep for "goto " in the Linux kernel sources, you'll find several hundreds of occurrences.

gose• 15 years ago

Here's Mac OS X's:

http://www.opensource.apple.com/source/shell_cmds/shell_cmds...

It's close to the FreeBSD implementation.

p9idf7• 15 years ago

cat.c is also interesting. The GNU version is an appalling unreadable mess. V6's assembly implementation in easier to understand.

V6: http://www.bsdlover.cn/study/UnixTree/V6/usr/source/s1/cat.s... V7: http://www.bsdlover.cn/study/UnixTree/V7/usr/src/cmd/cat.c.h... Plan 9: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c BSD: http://www.koders.com/c/fidF501905968D8BE7BBDD355C3C8DB62804... GNU: http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat...

bdonlan3• 15 years ago

V6's assembly version also does less. The reason GNU's is so complex is because it has a line-numbering feature (cat -n) not supported in V6 or V7, and also tries to read and write large chunks, to avoid overhead from calling stdio functions in a loop. It also tries to take advantage of non-portable extensions where possible, but fall back to portable code when not supported. Yeah, it looks a bit complex at first, but it's not really that bad if you actually take the time to read it.

p9idf7• 15 years ago

Those features simply do not belong in a program whose purpose is to concatenate its input. If you want to number a file's lines, 'echo ,n | ed file | sed 1d' or 'awk ''{ print NR " " $0 }''' will do just fine. You could even wrap your ed or awk script into a shell script with a descriptive name like "lineno" rather than something silly like "cat -n". The reason GNU's is so complex is because it does many things and does them poorly. The V6 implementation does exactly what is says on the tin, does it well, and does nothing more: it catenates files.

cpeterso3• 15 years ago

GNU's Hello World (version 2.7) example is 586 KB gzipped.

https://www.gnu.org/software/hello/

rat• 15 years ago

"The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.

However, unlike the minimal version often seen, GNU Hello processes its argument list to modify its behavior, supports greetings in many languages, and so on. The primary purpose of GNU Hello is to demonstrate how to write other programs that do these things; it serves as a model for GNU coding standards and GNU maintainer practices."

schiptsov• 15 years ago

touch.c is another good example. Especially one from Open Solaris. ^_^

alister• 15 years ago

I just wish that in the early UNIX days they reserved some of the flags to mean one thing only, and required all commands to have them (where it made sense). Like:

-r recursive (i.e., it should always be recursive mode if a command operates on files, and should always exist if it makes sense for that command)

-v verbose

-s sort

-i ignore case

-q quiet (suppress output)

If there were, say, 20 well-chosen standard flags (and they were enforced) it could have given the UNIX tools another level of nice regularity.

Unix V5, OpenBSD, Plan 9, FreeBSD, and GNU implementations of echo.c

Related Stories