The title is very misleading, judging the whole userland with this example is just unfair, besides, FreeBSD's one isn't pretty either still the OP choose to only bash on GNU.
Also, if you actually read the code it's the --help that takes up most lines in GNU's case. That's probably a standard inside coreutils codebase.
This shit again? And this time with such a bullshit title...
GNU echo simply does a lot more than the other echo implementations. And believe me it's much more useful in daily usage. That's why the GNU tools are so successful. All the minimal (often broken) utilities you had to use on commercial Unices were no fun. So everybody installed the GNU stuff.
I use -e and -n options of GNU echo regularly. Even if
So the GNU command line utilities do much more than their minimal counterparts on other Unix platforms and this was a reason for why they became so popular. Then this would be an argument against "Do one thing and do it well." This needs to be brought up whenever anyone extolls the Unix philosophy.
GNU code is ornate. GNU code always tries to do more than other implementations of tools.
"Quality" is in the eye of the beholder. Some people might like the extra features and in the usage documentation built into the GNU product. Other people hate every excess line of code that they need to maintain.
Another part of the reason is that GNU code, historically, tried on purpose to look different at the source code level from other Unix systems, to reduce the possibility of accusations of illegal copying.
I find the FreeBSD one more embarassing, to be honest. The GNU version just does a ton of annex stuff (hex handling, usage(), etc). I have no idea what the hell the FreeBSD one is trying to do.
The FreeBSD version is building up an iovec (which is effectively an array of (pointer, length) tuples) to pass to writev. I believe this is done for two reasons --
1) It reduces the number of syscalls -- a single call to writev outputs everything, rather than multiple fputs calls which may or may not be buffered (I haven't checked the impl details of fputs).
2) It reduces the number of allocations. Since an iovec is just an array of pointers, we can reused the data passed in via argv; the length of the iovec is capped at argc, so we can get away with one allocation without scanning the input.
For a comparison, here's a brief overview of each of the implementations (assuming fprint/fputs is not buffered):
* Unix V5: 0 allocations, N syscalls, no argv scan
* OpenBSD: 0 allocations, N syscalls, no argv scan
* Plan 9: 1 allocation, 1 syscall, scans argv
* FreeBSD: 1 allocation, 1 syscall, no argv scan
* GNU (without -e): 0 allocations, N syscalls, no argv scan
"argv scan" basically means calling strlen on every passed argument, or otherwise iterating over them. Naturally, "which one is faster" depends on how fast your allocations/syscalls/strlen's are, and how fprint/fputs is buffered.
If you have multiple programs writing to the same terminal, their write calls can get interleaved. To ensure that a single echo command's output remains unbroken, it should be output using a single write call.
GNU relies on stdio's buffering for this. Plan 9 allocates a buffer for the entire output and copies the arguments there.
FreeBSD wants to avoid linking to stdio, and wants to avoid copying memory (both for reasons of efficiency, presumably), so it uses the writev call instead, which lets you pass the kernel an array of buffers to write, without having to build up a single buffer in advance.
GNU userland is more usable and complete. It's also occasionally a little gilded.
When working on Solaris or OS X, one of the first things I do is get the GNU utilities into my path ahead of native ones. That way, I get the same environment on all 4 platforms I use - Cygwin, Linux, OS X and Solaris.
Among the many problems with glibc's malloc (when I tested, anyway) is that it slows down considerably as soon as you start up a thread, even if you immediately shut it down.
Not surprised at all that this translated to "...is not Plan 9" (I would've counted "was not written by DJB", too).
There seems to be some kind of computer nerd pecking order, similar to the "Trekkie->Larper->Furry" sequence. Lispers->Smalltalkers->Linuxers->9fans? (With Niklaus Wirth standing on the sideline, shaking his head)
Also, if you actually read the code it's the --help that takes up most lines in GNU's case. That's probably a standard inside coreutils codebase.