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.”
I have a notesfile on how to fix/debug things. When I started it, I would write things down after I fixed something and figured I'd need to remember it later.
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.
this is why I have made it a point these days that when I fix an issue, I immediately go to all the forums, subreddits and stackoverflow sites where I posted the question and post the relevant solution. Its a lot of work but totally beats figuring out what you did 6 months later
That’s just karma. I have tried not to do that to myself because so many others have done it to me. Still, sometimes the answer I left is too vague to be practical.
I make a habit of turning every question I have, that I don't find an answer to in 30 min, a question AND answer on stackoverflow/stackexchange
And many times, even years later, when I google the answer, I google my name, stackoverflow, and the topic, and kapow - answer received :D
Oh man this happened to me last month. I was even wondering how this guy had the exact same issue that I was having and only realized after a while that it was literally me who posted it. I eventually found an answer and decided to post an answer in case future me forgets it again.
I've also had this happen, but never figured out the solution.
This is especially frustrating because your question is likely to pop up first in your search results because you probably phrase things the same way even years later!
From a comment I saved several days ago:
> we don't have to figure it out - we just need to remember what we did
Allow me to recommend Kim Stanley Robinson’s _Icehenge_.
this kind of job is very memory constrained
you get into a task, you cram stuff in as you go, you finish it, and then you dump everything go onto another task.
i find my most valuable skill is to slow the pace to ensure retention of information
Still less efficient than dumping your piece of knowledge insomzthing like a second brain, aka personal knowledge management. The tricky part is whether to write down everything and make your notes too long to read/follow, or summarise things with the risk of forgetting an important piece of info [why you should do this or that, what you should NOT do, what additional piece of knowledge is required, etc]. The art of taking smart notes is really fascinating.
It boils down to the same issue. Whether you store data or not, your brain is a bottle eck. And managing notes would require the same skill as curating your efforts.
I go through the same thing but with a few "popular" GitHub issues. Every time I encounter those bugs I Google it and the first result in my comment on the issue that explains the workaround I used.
That's probably how early Alzheimer feels.
I sometimes have to go back to GitHub issues I created, that I bookmarked for this specific reason.
I think that the Internet has modified how our brains retain information. I don't think this is an original idea, but I've observed that I'm real good at indexing where I saw some piece of information and very poor at storing the actual piece of information. I have to physically write things down to commit them to recallable memory.
Physically writing things has been a useful tool to increase recall for a long time. Taking notes in class may be more helpful than reviewing them later.
Certainly, quick access to information with a small search query helps tune our brains to get small search queries, but do some filing for a day or three and your brain will get tuned to quick recall there too. In the old days, you'd get real familiar with certain parts of books.
I suspect our brains have always been better at remembering meta-information than information itself. E.g. where you last saw an item of clothing vs the configuration of colours on it. In most cases this makes sense, and is essentially a space-saving trick, but there must be some point at which the meta-info becomes too inaccessible or too slow to utilise that remembering the full detail directly becomes worthwhile. Convincing your brain of that before it becomes too late can be a regular challenge with so much readily available externally stored information.
My favorite pattern is to go look for an answer in the StackExchange network, find myself nodding in agreement with one of the answers, then read the author... me, 10 years ago!
That feeling when you go on a rant about how something was done in a super confusing way, so you do a ‘git blame’ or equivalent - and it’s all your fault. Oops.
This is why there's a "from:" line in the standard commit message template I introduced for my group of teams. If there's a ticket, bug report, user story, specification change, or standards reason for the commit I want to know that later. Sometimes that makes it into the code comments, and sometimes into the docs. It's always in the commit.
I wonder if anyone here is discovering that they also posted their comment in the previous links.
After a number of rounds of the game, “who wrote this garbage? I wrote this garbage” I began to recognize my own particular code writing style.
I still get nerdsniped though if certain people start copying my idioms and introduce bugs, because this looks like something I would write but didn’t.
Think of the people you've helped get their jobs done over the years. That's worth more than author credit in the colophon of a man page.
I get a little offended by people who think stackoverflow is a character flaw. I go there because it will tell me things like if you get the arguments to ‘dd’ wrong you’ll zero out the drive you were trying to back up. That the function breaks if you pass in null for the second parameter. Or that it simply doesn’t work properly.
I used the if= and of= command line parameters last time I used dd: https://man7.org/linux/man-pages/man1/dd.1.html
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!
What would you recommend as an alternative for disk imaging in Linux? I'm in the process of migrating a herd of PCs from HDDs to SSDs and would appreciate suggestions.
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:
will create a soft link in the CWD named baz, pointing to /foo/bar/baz.
ln -s /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.
> logically, the source must be the first one!
You mean the target, but that isn’t a logically necessary consequence at all. Conceivably, `ln` could support the following two syntaxes:
The way I remember the correct parameter order is that I remember it’s the non-intuitive one.
ln [options] target ln [options] link_name target
I remember this as "ln=long -s=short $long $short" as in "ln -s $long $short" creates a $short file pointing to $longfile. But to your point, $short is defaulted to basename($long).
The other way to think about it is that it's the same order as cp.
Finally! Somehow I've never been able to remember that either.
i've always considered manpages to be sort of part of the unix command line experience. since they're fast, it's no matter.
but yea, it took me many years to wire down ln's target link_name semantics for some reason.
what helped for me was to reason about the single argument form. ln -s ~/opt/junk/bin/thinger creates a link to thinger in the current directory. this single argument form is easy to remember, if you want to create a link of course you have to specify the name of the target (from which the link name will be inferred) and since it's the only argument it has to be the first one. now if you want to give it a different name, put the name in obvious still open place, the second argument.
Funny, I always reason about the 3+ argument form... For example, what does ln -s foo bar baz do? Well it can't create a foo symlink that points to bar AND baz, but it could create multiple symlinks - bar and baz - that point to the file foo. Therefore the first arg is the file you want to point to, and the rest of the arguments are symlinks you want to create (of which there happens to usually only be one).
Edit: this line of reasoning works for common usage of a lot of other utils too, like zip/tar etc. Even grep - is it grep FILE PATTERN [PATTERN ...] or grep PATTERN FILE [FILE ...] ?
“Same argument order as cp” always helped me.
Mnemonic: “What you have to what you want”
i'm enjoying seeing the variety in everyone's mnemonics :)
I learned to behave as if there is no second argument for ln. Instead of doing `ln -s path/to/foo bar` I do `ln -s path/to/foo` then `mv foo bar`. Of course it doesn't always work, but covers most use cases for me.
I generally only need `ln -s <src> <dst>`. I know the -s means symbolic link, but in my head I read it as "source", since that's how I remembered the order long ago.
This is confusing, because when you picture the link as an arrow (as in `ls` output), the link name is the source and the link target is the destination.
I think what a lot of people don’t get about the Unix command line is that learning to use the tool is part of the experience. Sure I forget the precise flags to get various tools doing what I need, but browsing the man page and rediscovering the breadth of the tool is half the beauty.
The only feeling I've gotten looking at a man page is, "well, I don't have to time to dig through all of this. Guess I'll just look at stack overflow which will have my exact use case and required parameters."
In my opinion, the EXAMPLES section should be near the top of the man page and include the most common usages.
What? That’s some intense Stockholm syndrome right there.
I remember the times before I learned Bash and the Unix userland. Those where dark times. I was stuck on Windows 98, which I really didn’t like. It just felt so needlessly crippled. When I discovered Bash, Debian, the Unix way, it felt like a breath of fresh air.
These days I’m on macOS. And one of the best things about it is that it’s a great desktop operating system, with a Unix under the hood. The userland Apple ships is quite dated, but that’s easily solvable by installing GNU Coreutils etc via Homebrew.
nah. learning unix was fun. having all the documentation online and in an easily called up and consistent format made it possible. microcomputer operating systems didn't have things like "man -k" and while we can complain all day here till we're blue in the face about small quirks, it was light-years beyond the crap that was going on in microcomputer operating systems.
even when doing windows or embedded development with tools like visual studio or wrs tornado, i've always insisted on having mkl or cygwin for command line tasks.
This is why imo powershell (when done right) is more powerful than bash (no matter how correctly it’s done). Powershell cmdlet names are descriptive and generally make sense as do the parameter names, additionally the guidelines for how to make powershell commands forces a certain style that once you grok it makes sense for most powershell commands.
If bash has something like that I’m still missing it.
Obviously the brevity of bash can be its own power.
I do feel like we are all a little beholden to bash and it is tiring. While I will put simple work into simple bash scripts I always use shellcheck and do ‘set -euo pipefail’. For the life of me I can’t remember what that is or why I need it, I just know that I do. (I’d be comfortable looking it up if I actually cared enough to.)
Anything more than trivial I do in a high level programming language like Go (previously I would use Ruby or Perl).
From everything I’ve seen PS is a nice direction to go in.
I wish there was a sudden upheaval and everybody used a shell that wasn’t so legacy-cruft-laden.
PowerShell’s learning curve was too steep for me (or maybe I didn’t try hard enough, idk). I used it for a couple of years, but once WSL turned up I went back to my trusty old Linux skills.
The brevity is great when used interactively.
For scripting you can always use Python, which is lightyears ahead of PS.
"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.
I don't mind the slightly different versions, that's what documentation and SO is for. I mind the language being a garbage kludge of organically-grown syntax and semantics, with not the slightest hint of a single principle or a unifying idea. And I mind that the vast majority of interfaces to it from a general purpose PL is fucking around with strings like a caveman, instead of a typed, IDE-assisted, first-class representation as a full-blown language construct or mix of constructs
I agree. I actually have a pretty strong understanding of regexes and use them regularly (for editing, not so much in code), but I despise how every editor/language does them subtly different.
Truly relevant XKCD https://xkcd.com/1168/
I’ve never understood that one. I realize it’s just a joke, but xvf/cfv (extract/compress, view, uh,. Ok I did have to look up f, which I think is file) and the z for gzip is one of the few commands I have no trouble remembering.
Though if you include the dash to use those as flags, the second one is wrong (it treats the "v" as the file name for "f"). Without the dash, the next positional argument is the file name.
Examples: These do the same thing:
This errors, trying to add foo.tar to archive v:
tar cfv foo.tar a b c tar cvf foo.tar a b c tar -cvf foo.tar a b c
tar -cfv foo.tar a b c
Even easier: tar --help
Reminds me of a peeve I had with the Apple docs when they described Bash like riding a bike (but in a different metaphor - it's good to get around somewhere easily but won't take you as far as an application language)