Hacker News Reader

Comment by kryptiskt | Hacker News Reader

And you get a better grounding in the Unix philosophy if you omit the command line switches and make small utilities to handle those cases, because as the paper said, cat -v is harmful (http://harmful.cat-v.org/cat-v/unix_prog_design.pdf).

View on HN

The Unix philosophy is somewhat of a myth. http://cm.bell-labs.com/cm/cs/who/dmr/man12.pdf shows that that same first edition already had a -t option on ls. Surely, that should have been some | sort, but AFAICT, they did not bother to write that until some later time.

Sticking to a philosophy like a zealot makes it a religion. Keeping it as a philosophy means it encourages a certain approach, not that it makes it an absolute unbreakable rule, plus it would only results in bikeshed/flamewar arguments.

as PEP20 says:

    Special cases aren't special enough to break the rules.
    Although practicality beats purity.

I said "somewhat" for a reason, but I think there are just too many special cases to keep calling them exceptions. I use awk and sed, pipe things into bzip2, but I more often use tar with a z or j option to compress stuff an in a pipeline. We also do not have separate tools for parsing python/ruby/perl and executing it. If code reuse using pipes were successful, wouldn't we have a separate 'exec' tool that is backend to all scripting languages? Looking at gcc with its zillions of options, pipes sometimes look more like an implementation detail than as the primary way to compose tools.

Also, other kinds of reuse of the things mentioned as examples of the Unix philosophy are rare. What languages on your system use lex and yacc? 'but thise tools are outdated' is not a good revuttal; if they are, how has that come about? I think the Unix philosophy is perfect for prototyping, but 'real' stuff tends to need polish that 'the unix philosophy' cannot provide. As a final example, consider git. As I understand , it started life as a set of scripts, but eventually became a C program.

I generally use the -j option to tar primarily because it's less typing. I think the ideal option is for these flags to be provided, but implemented using pipes under the hood so tar -cj folder is just syntactic sugar for tar -c | bzip2. Similarly, tar -cf folder.tar folder/ could be implemented as tar -c folder/ > folder.tar. I think this way you get the conciseness of the flags approach, but also each item of functionality is only implemented once. Just a random thought.

Thank you so much for the link. It was clear, succint and a wonderful explication of the oft-discussed, never explained, Unix philosophy.

I look at the options for cat on my ubuntu system though, and realise that this problem has only gotten worse.

Holy wow. I had read about "Cat -v considered harmful", and I was familiar with cat-v.org, but I didn't realize the inspiration from cat-v.org's name.

Reply on news.ycombinator.com