4 ms·

Most Unix CLI tools don't respect the unix philosophy anyway. For example a lot support something like `--output file.txt` when the Unix philosophy would say to

Most Unix CLI tools don't respect the unix philosophy anyway. For example a lot support something like `--output file.txt` when the Unix philosophy would say to not implement that and just use `>> file.txt`

bayindirh 1y ago
From my experience, --output is a minority in my workflow. Which tools do you use need --output?
- oneeyedpigeon 1y ago
  Coincidentally, I went looking for some the other day and there were very few. Everything that uses --output for this purpose, that I could find, was a compiler.
  - deleted 1y ago
    [deleted]
- onestay42 1y ago
  dd an company require if= and of=, if that counts
  - bayindirh 1y ago
    dd doesn't require either if= or of=. It'll read from stdin (or pipe) if you omit if= and it'll write to stdout happily if you omit of=. From the man page: if=FILE - read from FILE instead of stdin. of=FILE - write to FILE instead of stdout. So you can do: cat x.iso | dd oflag=direct bs=4096kB | /dev/sdc
weinzierl 1y ago
I think practical Unix philosophy is more nuanced. There are filter programs that read STDIN and write to STDOUT per default. But this is not really practical for many use cases which are not filters first and foremost. So we end up with still reading from STDIN or the list of files presented as arguments. We write to the file given by -o (or --output) which can be "-" to signify STDOUT. I find this pattern very flexible because it allows multiple input files or STDIN and a single output file which can be STOUT, so you still get your filtering behaviour if you want. (For completeness sake, there is a third pattern somewhat prevalent. In call these copy type programs. They treat the last argument specially, usually as some form of target, like `cp a b c target`.)
- dist-epoch 1y ago
  --output was just one example. Many tools provide formatting options, ls can sort, find can delete files it finds, and so on.
  - bayindirh 1y ago
    I don't believe programs able to sort their output is acting against the UNIX philosophy. "ls" lists files and does a good job of it. find's -exec is a bit stretching it (-delete came later IIRC), but generally it adheres the philosophy pretty well. From my experience of programming small utilities for myself, UNIX philosophy says "a tool handles a single job and handles it well" is a nod to fallacy of "gluing" things together. Because when you start to glue things beyond simple pipes, the glue code becomes exponentially complex and takes more and more of the program, which creates a maintenance hell and affects performance (much more profoundly on a PDP). So, simple tools doing single things is both easier to write and maintain, and they're much more performant in general. Remember the guy who left a whole Hadoop cluster in the dust with GNU command line tools and some pipes, on a small laptop.

bayindirh 1y ago

From my experience, --output is a minority in my workflow. Which tools do you use need --output?

oneeyedpigeon 1y ago
Coincidentally, I went looking for some the other day and there were very few. Everything that uses --output for this purpose, that I could find, was a compiler.
- deleted 1y ago
  [deleted]
onestay42 1y ago
dd an company require if= and of=, if that counts
- bayindirh 1y ago
  dd doesn't require either if= or of=. It'll read from stdin (or pipe) if you omit if= and it'll write to stdout happily if you omit of=. From the man page: if=FILE - read from FILE instead of stdin. of=FILE - write to FILE instead of stdout. So you can do: cat x.iso | dd oflag=direct bs=4096kB | /dev/sdc

weinzierl 1y ago

I think practical Unix philosophy is more nuanced. There are filter programs that read STDIN and write to STDOUT per default. But this is not really practical for many use cases which are not filters first and foremost. So we end up with still reading from STDIN or the list of files presented as arguments. We write to the file given by -o (or --output) which can be "-" to signify STDOUT. I find this pattern very flexible because it allows multiple input files or STDIN and a single output file which can be STOUT, so you still get your filtering behaviour if you want. (For completeness sake, there is a third pattern somewhat prevalent. In call these copy type programs. They treat the last argument specially, usually as some form of target, like `cp a b c target`.)

dist-epoch 1y ago
--output was just one example. Many tools provide formatting options, ls can sort, find can delete files it finds, and so on.
- bayindirh 1y ago
  I don't believe programs able to sort their output is acting against the UNIX philosophy. "ls" lists files and does a good job of it. find's -exec is a bit stretching it (-delete came later IIRC), but generally it adheres the philosophy pretty well. From my experience of programming small utilities for myself, UNIX philosophy says "a tool handles a single job and handles it well" is a nod to fallacy of "gluing" things together. Because when you start to glue things beyond simple pipes, the glue code becomes exponentially complex and takes more and more of the program, which creates a maintenance hell and affects performance (much more profoundly on a PDP). So, simple tools doing single things is both easier to write and maintain, and they're much more performant in general. Remember the guy who left a whole Hadoop cluster in the dust with GNU command line tools and some pipes, on a small laptop.