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?

  • it can already do this ... it's just flexibility to make the command shorter – xenoterracide Nov 19 '11 at 21:25
  • Some old, minimal systems did this with some commands. The gzip on tomsrtbt (which I think came from busybox) for instance only worked on stdin and wrote to stdout. Functional, but a pain in the butt. – dmckee --- ex-moderator kitten Nov 20 '11 at 17:22

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).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.