121–130 of 150 posts
I live by command line history and timestamps. I wish there was even better way to preserve the context of what you were doing at the time (env variables, current path at the time etc).
PS: be sure to always have a -—help option that describes the function, just as you would do when programming
Earlier quoted context omitted.
Ah, I remember it is the non-intuitive one, but then when I use it a while, I keep double-guessing which one is the intuitive one. Kind of like when my wife tells me I'm doing something wrong and she wants it to be the other way.. I know she thinks this thing is important, but can't work out which way she wants it done.
The intuitive one is the order in which `ls` displays it, or assignment order (a := b). That’s how I remember what the intuitive order is. ;)
Earlier quoted context omitted.
Worse : You Google a question and realise you yourself asked it many moons ago and it never got answered.
Worst: you find your own answer that says: “Nvm, fixed the issue.”
Problem was, I would often forget to write things down, or naively think "that was quick to find out, don't need to write it down", which is a classic mistake of confusing post-facto mindset with pre-facto.
So now when I wonder how to do a thing, I first write down in my notesfile what my question is, so when I do resolve it I go and write down the answer to satisfy my need for closure.
Earlier quoted context omitted.
I think that using dd is a character flaw.
To expand on this, people needlessly cargo-cult arcane dd commands, but on many (most?) systems, "cp foo.iso /dev/sdb" will do the same thing, but with possibly even better performance!
Earlier quoted context omitted.
What finally got the `ln` argument order engraved in my mind was learning that you can skip the destination argument: ln -s /foo/bar/baz will create a soft link in the CWD named baz, pointing to /foo/bar/baz. So you see, if you know that you can always skip the destination, then, logically, the source must be the first one!
I'd say the easiest way to remember the argument order is that it's conceptually the same as for mv and cp: ln -s x y is the closest possible symlink-analogue of cp x y.
Zen Koan: Before I began my studies in Zen, I thought a tree was a tree and a stone, a stone. When I started to study Zen, I could see that a tree was not a tree, and a stone was not a stone. Now that I am a Zen master, I know that a tree is a tree and a stone is a stone. -- Source: my buddy in college I think you come full circle to learn that you can only keep so much in your head at one time and that you're always…
It is pretty cool. When I was little I had no idea what it means, just knew that it sounds cool. But the older I get that more I see these patterns. junior dev: python is so cool! senior dev: python is slow. No type checking. The syntax is garbage. John Carmack: I write a lot of python and I use it exactly for what it is good for!
Earlier quoted context omitted.
"It's like regex" could be another punchline for the joke
My biggest problem with regex is each language/program/whatever has their own take on it. You don't have to learn it over and over, you have to learn multiple slightly different versions of it over and over.
Earlier quoted context omitted.
I use the `ln` command a lot. I use the `man ln` command _almost_ as much.
What finally got the `ln` argument order engraved in my mind was learning that you can skip the destination argument: ln -s /foo/bar/baz will create a soft link in the CWD named baz, pointing to /foo/bar/baz. So you see, if you know that you can always skip the destination, then, logically, the source must be the first one!