11 ms·
Unix V5, OpenBSD, Plan 9, FreeBSD, and GNU implementations of echo.c
- IvarTJ 15y agoThat 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 15y agoNah, 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/ 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 15y agoi 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.
- icebraining 15y agoI think their point is that you should separate it in different utilities/binaries which would be very simple and have less bugs, and let users combine them as they wish. For example, instead of cat -v, you'd have a second utility called, 'nonprint' which would just translate non-printing chars, and you'd call it using cat file1 file2 | nonprint
- coliveira 15y agoYou are making the system more complicated for everyone because of features that only a few users know about. This is how code bloat starts its life cycle. If you need more features from a basic utility like echo or cat you should create your own version, maybe with a slightly different name, and leave the original as it is.
- Duff 15y agoThat's exactly what happened. Those crazy kids at Berkeley cooked up BSD, which was written to meet their needs and subsequently forked into a few variants. The GNU people made a GNU collection of core utilities that met their particular needs and desires. The Unix nerds at my University felt as you did, and ran a Unix System 5 variant into the late 90's.
- Confusion 15y agoYou are making the system more complicated for everyone because of a program that only a few users know about. That is how code bloat starts its life cycle. If you need a basic utility like echo or cat, you should create your own version and don't bother others with it.
- xilun0 15y agoNot a very good strategy to avoid bloat... Not even mentioning you will end up with 100 times the number of tools you have now. I would not call such a system more simple, indeed it would be inferior on all possible points. In a real system, even basic utilities rarely looks like a CS101 homework result. This is perfectly fine, especially in this case the amount of feature in gnu echo is perfectly reasonable, and the size of the executable will likely depends on various header than code size when the code is so small anyway.
- bdonlan 15y ago/bin/echo on debian sid (x86): 13 .text 000028dc 08048b90 08048b90 00000b90 24 CONTENTS, ALLOC, LOAD, READONLY, CODE /bin/cat on debian sid (x86): 13 .text 0000775c 080491b0 080491b0 000011b0 24 CONTENTS, ALLOC, LOAD, READONLY, CODE That's 12kb and 32kb, respectively. It may have been a lot back in the day, but it's plenty small enough on today's systems.
- 1337p337 15y agoIt's just good practice, in general, to keep individual programs simple. If you have a look at DMR's description of why the pipe was invented, it suddenly clicks. All of these tools are intended to be composable, analogous to functions. 'cat -v' is like a function with too many arguments, one that does too much. If you need, for example, to allocate a block of zero'd memory, you don't add new flags to malloc(); you use memset() after allocation, you write a for loop, or you use calloc(). Likewise, the basic tools available on Unix can and should be thought of as functions, which take some number of arguments, and the implicit argument of an input channel. They produce as their output an integer as a return value and two output channels, stdout and stderr. Making a function that does too much (and this is as subjective for functions as it is for command-line tools) is known to be bad practice, but for the shell, it is often misunderstood. To misunderstand this is to misunderstand the core principals of the Unix environment. It has nothing to do with the typical non-programmer user. On, say, Linux or OSX, the user doesn't write functions or talk to the shell very often. They click buttons in a GUI that doesn't in a meaningful sense offer composable programs, and it's an inefficient but simple way to interact with the machine, a way that matches their habits and understanding. cat, echo, sed, and awk aren't for these users; they're for programmers, and the typical user does not know or care whether cat can show non-printing characters, but as a programmer, I certainly care about a clean design for my environment.
- nvictor 15y agowow :O
- scythe 15y agoOkay, 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.
- mikelward 15y 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.
- scythe 15y agoOh, that makes sense. Speaking of clever tricks, would it be faster or slower to use c99's variable-length arrays instead of malloc?
- alexgartrell 15y agoIIRC faster, because variable-length arrays in c99 just bump down the stack pointer, while malloc can be pretty expensive. But a single malloc is nothing compared to the cost of a context switch into kernel mode.
- chaosfox 15y agoslightly 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
- deleted 15y ago[deleted]
- pixelbeat 15y agoOne should avoid echo anyway due to portability issues. Use printf instead.
- robtoo 15y agoMore *nix systems have a /bin/echo than /bin/printf or /usr/bin/printf
- mikelward 15y agoYes, 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.
- mikelward 15y agoThe "-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.
- ilikejam 15y agoSure you can: dave@cronus $ ./echo -n "-n dave@cronus > " -n dave@cronus $ Not pretty, though.
- mikelward 15y agoYou're right. I should have said "no sane way to do it". :-)
- martinp 15y agoOr echo -en "-n\n".
- mturmon 15y agoCute, 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.
- ilikejam 15y agoSo... [dave@mini ~]$ echo -n "-n foo > " -n foo [dave@mini ~]$ Easy!
- mikelward 15y agoYou can see the original UNIX sources at http://minnie.tuhs.org/cgi-bin/utree.pl http://minnie.tuhs.org/cgi-bin/utree.pl
- hackermom 15y agoFollowing 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.
- p9idf 15y agoBash'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/echo.def http://git.savannah.gnu.org/cgit/bash.git/plain/builtins/ech... http://git.savannah.gnu.org/cgit/bash.git/plain/support/recho.c http://git.savannah.gnu.org/cgit/bash.git/plain/support/rech... http://git.savannah.gnu.org/cgit/bash.git/plain/support/zecho.c http://git.savannah.gnu.org/cgit/bash.git/plain/support/zech...
- deleted 15y ago[deleted]
- pyre 15y 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 15y agoI do not have much experience reading C code. Is the use of gotos and labels in the GNU code common?
- Peaker 15y agoFor 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.
- sjs 15y agoIn 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.
- sliverstorm 15y agoError 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?
- sparky 15y agoIn both cases, to avoid duplicating code. If you malloc() something in your function and intend on free()ing it before returning, it's often considered best practices to write the return block (which includes the free()s) once, and use "goto returnblocklabel" if you need to return early. So rather than this: void test() { int *x = malloc(1000); int *y = malloc(1000); for(int i = 0; i < 999; i++) { if(badThing) { free(x); free(y); return; } doStuff() if(otherBadThing) { free(x); free(y); return; } } free(x); free(y); return; } You'd have: void test() { int *x = malloc(1000); int *y = malloc(1000); for(int i = 0; i < 999; i++) { if(badThing) goto ret; doStuff() if(otherBadThing) goto ret; } ret: free(x); free(y); return; }
- gose 15y agoHere's Mac OS X's: http://www.opensource.apple.com/source/shell_cmds/shell_cmds-149/echo/echo.c http://www.opensource.apple.com/source/shell_cmds/shell_cmds... It's close to the FreeBSD implementation.
- p9idf 15y agocat.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.html 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.html 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 http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c BSD: http://www.koders.com/c/fidF501905968D8BE7BBDD355C3C8DB628048A0DEDE.aspx?s=netbsd#L1 http://www.koders.com/c/fidF501905968D8BE7BBDD355C3C8DB62804... GNU: http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat.c http://git.savannah.gnu.org/cgit/coreutils.git/plain/src/cat...
- bdonlan 15y agoV6'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.
- p9idf 15y agoThose 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.
- ez77 15y agoI liked your use of ed. You can avoid one pipe with the -s option: `echo ,n | ed -s file`. Also, another POSIX one-process option besides awk: `pr -tn file` (with different padding).
- deleted 15y ago[deleted]
- yuhong 15y agoSystem V (USG) UNIX is another mess altogether: http://groups.google.com/group/comp.unix.wizards/browse_frm/thread/8dd3ef2626dd756f http://groups.google.com/group/comp.unix.wizards/browse_frm/...
- schiptsov 15y agotouch.c is another good example. Especially one from Open Solaris. ^_^
- alister 15y agoI 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.