Hacker News Reader

Comment by randrews | Hacker News Reader

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment:

Late at night, I was tarring up a finished project right before emailing it to my professor. I ran:

    tar -cvf *.cpp *.h something.tar

instead of:

    tar -cvf something.tar *.cpp *.h

It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar didn't exist. I overwrote "array.cpp" or something like that, and had to rewrite it (this was before I used source control for anything, and a large part of why I learned to use source control).

Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar.

View on HN

I think personal experiences with shell command typo disasters and hard drive failures are probably the most common, and most effective reasons why people start using version control and backups religiously. The Unix command-line in particular is dangerous: incredibly powerful when used right, but one slight mistake and you cut off a finger.

Fortunately, they are only virtual fingers and we can grow them back on demand with adequate preparation, unlike real ones. :)

Version control is also fantastic because you can think a lot less about making drastic edits. Gone are the days when I would keep bits of code commented out "just in case" I needed it back at some point.

Mostly, although I take issue with the "never leave commented code around, that's what version control is for" as an absolute. If it's something that is not adequately replaced, and is likely to save some time for someone in the future then it's better to keep it commented out rather than removing it since future devs may never know it even existed.

Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar.

The -f (--file) flag takes an argument. So you could do:

    tar -cf *.cpp -f something.tar

It is easier to remember order if you know what the flags mean.

It's true, and I'll probably remember it now. But, since I have every single time used the -f flag, it would make a lot more sense for it to say "you asked me to compress a file that doesn't exist and ends in .tar; I bet that's what you meant the -f parameter to use" and fix it for me.

I'd rather not have my tools perform magical heuristics to try to figure out what I meant to do.

The "-f <filename>" flag is perfectly clear, and useful in all modes (c, x, etc). If you remember "tar czf" as a magical incantation, then you're missing something vital. When you understand what each argument means there is no ambiguity. I don't mean to sound condescending, but in my entire life I've never encountered the problem you described.

It is too late to edit my above comment but I should point out that there is a typo there. That should be:

    tar -c *.cpp -f something.tar

> Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar

    ; tar c *.cpp *.h >something.tar
    ; tar c dir | gzip >something-else.tgz

Problem solved! Also:

    ; tar c dir | gzip | nc -q0 -lp 4000 &
    ; [another computer]
    ; nc $otherhost 4000 | gnuzip | tar x

Man, that is scary. These days with Dropbox and github and TimeMachine, I rarely worry.

Reply on news.ycombinator.com