The classic example, which you should only try if you have saved all work, is:
: () { :|:& }; :

It’s perhaps more obvious what’s going on if you replace : with a word and indent:
bomb () {
    bomb | bomb &
};
bomb

On Linux (I’m not sure about anything else), it is safe (ish) to run only if you limit the maximum number of processes first, with ulimit -u 100.

Bash and dash and probably some other popular shells will let you create unlimited-length command strings, so they’ll keep malloc()ing more memory until that fails.  The rest of the user’s system presumably reacted the way it would to any command that tried to hog all the memory, but since it was probably the user’s main shell, he interpreted its lack of responsiveness to his input as a system problem.

Older Unix shells had fairly tight limits on command length, e.g. 1023, while bash and dash seem to keep allocating memory until the operating system won’t give them any more, and then produce error messages and crash. What do your favorite FreeBSD shells do?

I don’t see why the user had to restart his system just because the shell crashed, but I don’t know what environment he was running his shell in.  Ubuntu deals adequately with applications that want to hog all the memory and a bit of extra CPU, but maybe he filled up his disk drive with a core file or something?

Pro tip: try several different shells, such as bash and /bin/sh (which seems to be “dash” under Ubuntu), and run ntop in another window to get some feedback on what’s happening. 

Some versions of unix (e.g. many recent releases of OSX) don’t even enforce ulimit maximums for ram, which means you can crash a mac with a ram eating process, even if the admin set a ram limit for users.. which is a pretty grave omission:
https://discussions.apple.com/thread/3293075?start=0&tstart=0
http://lists.apple.com/archives/unix-porting/2005/Jun/msg00115.html

It’s my understanding (and a common situation) that if the ‘receiver’ end of a pipe is unable to “keep up”, the sender’s write operation should be blocked for I/O (put to sleep by the kernel) allowing the receiver to catch up and empty the buffer. If the receiver never catches up (ie. second yes(1) not even reading stdin), sender should remain blocked indefinitely.

No special code should be needed for this; write(2), printf(3), fwrite(3) should all behave this way IIRC, as this sounds like something the kernel should be doing during the low level write(2) operation..

  Command line Russian roulette 

[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*

Note: I know next to nix about Unix.

A month or so ago I was visiting my brother’s family when my Macbook froze. Force quitting through the keyboard didn’t work, so I powercycled it. Turned it on again, and the main partition was gone – only the rescue and Windows partitions showed. I started up through the rescue partition, and its disk utility indicated the hard drive itself was sound, but the main partition wouldn’t mount. Trying to start up the main partition in command line gave me more specific error codes that indicated its file structure was okay, but its journal was corrupted. The journal can be turned off, but to do so you have to mount the partition, and you can’t mount the partition while its journal is corrupted! :/

After cursing the heavens and doing some research on Google on another computer, I found that going into Terminal, entering “diskutil disableJournal force (partition name)”, ignoring the failure message, and entering “diskutil mount (partition name)” might work. Reset again, the main partition came back, and my niece & nephew got to play WoW again.

That’s like saying “a circular saw is a badly designed tool” because if you put your hand onto the running blade, it cuts your fingers off, or a fire hose is a badly designed tool because you can’t drink from it.

The second one would run indefinitely because it’s not checking its input, and as somebody noted upstream, the first one would run for a little bit but would get suspended once the pipe buffer filled, waiting for the second to begin reading it. The net output of the pipeline would be the same as if you had just run “yes”.

It’s good to have a clear mental model of what’s going on when you write shell scripts, and I have written a bunch.