Hacker News Reader

Comment by nikcub | Hacker News Reader

Your ruby version of cat implements none of the command line switches.

I learned C by going through the FreeBSD code and helping with POSIX compliance. For fun I would implement a lot of the commands in Python. You get the most out of learning both the language and UNIX by implementing all the command line options.

View on HN

"Your ruby version of cat implements none of the command line switches." I don't think he was trying to show off what a feature complete cat command he wrote. Just trying to illustrate his idea. No need to be rude about it.

It's a factually correct statement, nothing rude about it.

> It's a factually correct statement, nothing rude about it.

Facts can be stated in a rude manner; rude statements can be factually correct.

Asshole.

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

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.

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.

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.

But his version is a lot closer to the UNIX philosophy than GNU's version...

GNU is Not Unix

Reply on news.ycombinator.com