Your mentioning people “start[ing] using [commands] in ways their programmers never imagined” reminded me, a shell newbie, of something I had read a long time ago, which was that people who use `cat` to output a single file’s contents are using the program for something other than its intended purpose. That inspired me to experiment to find the correct way of echoing file contents.
I think the correct way is the `<` operator. `>` writes to a file, and `<` is the inverse, so it reads from a file. One shouldn’t `cat some-file.txt` or `cat some-file.txt | wc -l`; one should `< some-file.txt` or `< some-file.txt | wc -l`. `cat` is only necessary when you supply to it multiple arguments, as in `cat first-file.txt second-file.txt`.
Of course, `cat` still works for outputting file contents, as it has for me all this time. But it just feels more “right” and “safe” to use the operator that is built for that purpose.
I just wanted to mention that discovery in case anyone else wondered the same thing when they read the words about using commands in unintended ways.
Although in most cases the program you're using is capable of reading from both stdin and from a file. So you'd really just run
$ wc -l some-file.txt
When you see characters like '|', '<', and '>' the things you're playing with are called pipes. (There's a decent wikipedia article on 'Pipeline (UNIX)' that talks more about them) Having tons of commands that do specific things wouldn't be very useful if you couldn't compose them (in the function composition sense), and pipes are the tools you use to combine them. This is where the 'using commands in ways never imagined by their authors' really comes from.
To be pedantic, > and < aren't pipes, only | is. A pipeline means that stdout of the first program is stdin for the next program. > and < set stdout or stdin to a file, not another program.
Given the proximity of `<` and `>`, and the fact that `> somefile.txt` will silently truncate the file, I would take issue with the "safeness" claim :P
Also, `< file.txt | wc` doesn't work (at least not in bash; zsh (my install/plugin combo, at least) apparently tries to map the lone `< file.txt` to `less -R file.txt`...which spits out an error. Anyway, omitting the pipe will work: `< file.txt wc -l`
`cat` by definition concatenates one or more files and spits the output to stdout, so using it on a single file is perfectly within the bounds of its definition (IMHO; I realize people get really zealous about this type of thing and I'm not trying to start a war).
cat will actually launch a separate process, while redirection will not. Unless you're working on a very old machine or a low-spec embedded system, this shouldn't make much practical difference.
"< some-file.txt | wc -l" doesn't work for me. "< some-file.txt wc -l" does. I actually wasn't aware of the latter syntax; and now that I think about it, I'm actually not sure if I've ever used redirection in combination with piped commands.
(I don't do a whole lot of shell scripting, and I exclusively used DOS, Windows, and OS/2 during my most formative years, so my reflex is to reach for an actual programming language to do nontrivial things, because even though I've been using Linux for years as my main OS, the fact that I now have a competent shell available still hasn't completely sunk in. I was amazed when I discovered the xargs command and its --max-procs option; I'd written a Python script to do much the same thing.)
I think the correct way is the `<` operator. `>` writes to a file, and `<` is the inverse, so it reads from a file. One shouldn’t `cat some-file.txt` or `cat some-file.txt | wc -l`; one should `< some-file.txt` or `< some-file.txt | wc -l`. `cat` is only necessary when you supply to it multiple arguments, as in `cat first-file.txt second-file.txt`.
Of course, `cat` still works for outputting file contents, as it has for me all this time. But it just feels more “right” and “safe” to use the operator that is built for that purpose.
I just wanted to mention that discovery in case anyone else wondered the same thing when they read the words about using commands in unintended ways.