While I understand that programs like mv need an actual filename as a parameter, programs like sort could just read from standard input and write to standard output like names | sort > names instead of using a filename and providing options like -o: sort names -o names.
So what are the reasons behind this?
In short, it gives the programs a lot more flexibility and ease of use with very little extra programming. So why not?
Most core utilities that operate in an applicable manner do have that functionality. I'm not a perl programmer, but I believe the diamond operator <> acts the same way - read from files if they're present on the command line, or stdin otherwise). And I also seem to recall Larry saying that was so perl scripts could fairly easily emulate the core utilities in that feature.
More to the point, it allows the programs to act on many files at once, and they can tell them apart. Using cat, you couldn't do that. Without the names, you couldn't have utilities that act inline (sed -i), or those that differentiate based on the file (wc). It also looks cleaner (IMO): sort file -o sorted vs cat file | sort > sorted or sort <file >sorted (which, btw, will not work correctly inline, reading and write the same file).
gzipon tomsrtbt (which I think came from busybox) for instance only worked onstdinand wrote tostdout. Functional, but a pain in the butt. – dmckee --- ex-moderator kitten Nov 20 '11 at 17:22