There are commands, such as cd, pwd and date that just aren't going to pay attention to anything that is piped to them and commands -- cd anyway -- that don't generate any output that can be piped to other commands. You can type ls | ls and get a file listing, but that first ls is not going to be delivering its output to the second. Similarly, who | ls is going to give you the same result because ls isn't looking for content being piped to it. Knowing when to use a pipe involves becoming familiar enough with each command to know what you can do with them. Commands such as cd, mkdir, rmdir and touch don't generate output nor do they read and use content that is piped to them. You can issue a command such as echo hello | touch, but you're not going to create a file named "hello". Instead, you're just going to get a touch: missing file operand type of error. Other commands, such as head, tail, more and less can both generate output and read content that is piped to them. And, then, there are commands like ls and cal that do one (generate output), but not the other (read piped input) of the two pipe functions. When you think about Unix commands and pipes this way, it's not so surprising that neophytes find the learning curve of Unix a bit steep and might actually try commands such as who | ls or tail -1 dates | cd, never mind cat myfile | wc -l Once they fully understand when pipes work, when they don't work and when they don't contribute (and are, thus, useless), they'll be ready to work wonders on the command line.
Read more of Sandra Henry-Stocker's Unix as a Second Language blog and follow the latest IT news at ITworld, Twitter and Facebook.
flickr / Beige Alert