//*
normal path
/*/
debug path
//*/
#if 0
// Normal path
#else
// Debug path
#endif
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them. I have a directory of docs where I write stuff like this down by language/tool/etc., so I can quickly look it up without having to search the internet. But I also have to actively remind myself that these things exist whenever I have a problem, stop me from just doing the inefficient thing.
So if you want to use ctrl-r, but you’re using the up key, use the down key to navigate back to a clear line, then use ctrl-r. Do it enough times and your brain will work overtime to find a shortcut (aka just doing it the new way).
It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".
though one function that i recently added will narrow your history down based on a space separated set of filters which i found useful
function hgrep
set -l cmd history
for pattern in $argv
set cmd "$cmd | grep -- "(string escape "$pattern")
end
eval $cmd | cat
end
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
type eg "rg" then up or down arrow, and the history shown is filtered by that rg prefix.
bindkey '^[[A' history-search-backward
bindkey '^[[B' history-search-forward
Seems like overkill until it saves my ass. It continues to do so almost half a decade into all the LLM hype. It hits the sweet spot between simplicity, convenience, reliability, and precision.
People strongly underestimate how good the git life can be, especially with all the blogspam on here trying to dethrone it lately.
Don't let IT hear that unless you work on FOSS.
I think for a digital solution to come close you need it permanently present on a nth monitor
what a time to be alive.
yes, it's improved a lot in the last couple of years! what in particular bothered you?
Make sure you’re using the daemon (the install script will handle this) and you should be good to go
Very happy to help if you have any problems. Ellie at Atuin dot sh
People had this same problem last century. They would use templates that fit over their keyboards with all the common shortcuts and commands printed on them. Sometimes they were for a specific program, but you could buy blank ones to write your own notes.
Today, "keyboard templates" have an entirely different meaning, so the best thing for this is paper. Print your shortcuts out on a piece of paper and put it near your monitor. You could even categorize them by writing them on different-colored Post-Its.
I always wanted the same for Vim, zsh, etc.
Is this just plain old rage baiting? I literally can’t tell any more.
There are other terminal specific shortcuts for removing last word (ctrl+w) but they don't seem to be as portable.
I haven't put in enough effort to replicate the experience on GNOME but once I jump ship from Apple I'll have to.
The way macOS treats shortcuts thanks to the separation of Command and Control is great. It even makes Google Docs pretty painless to use because it's mostly like Emacs. Word still tries to hijack the shortcuts so that's suboptimal.
The advantage of doing it this way ('software flow control') is it worked with just TX and RX lines, rather than having to connect up additional wires to indicate when the terminal was busy ('hardware flow control').
stty -ixon
--date=2026-09-16
--date 20260916
and all variations thereof. It's annoying enough to have to check which script expects what format that I probably should've wasted some time or tokens to align them all, or at least put it into an MD file. But it's just an illustration of how LLMs can make CLI commands more obscure than they need to be.
Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.
The rest of us picks a level between "approve some" and "YOLO" depending on how much they worry about having to clean up the workspace afterwards. Encouraging using the repo and some dedicated per-session storage, while discouraging changes to global state (like installing packages system-wide) reduces cleanup problem to "every now and then `rm -rf` some agent session dirs".
Anyways I find it mind boggling how many useful actions are not known by „normal people”. Most people are really using computers in a very inefficient way.
My idea is if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents and we would triple GDP.
There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software. The AI companies looking to profit from renting out the collected works and creativity of humanity certainly wouldn't shut down if the GDP tripled either.
People should still take time to learn how to use computers though. As long as they're going to use computers they can save themselves a lot of trouble and anxiety by investing some time in learning about them a little. Same with many other things people use and depend on.
https://github.com/hiAndrewQuinn/shell-bling-ubuntu
More readable presentation: https://hiandrewquinn.github.io/shell-bling-ubuntu/
Among other things, fzf gets installed with all the proper key bindings, ripgrep, fdfind... basically every papercut I could find between going from a vanilla Ubuntu or Debian box to a configured one is handled in this shell script.
https://gist.github.com/GNOMES/6bf65926648e260d8023aebb9ede9...
I use this often instead of chaining together multiple '../..'.
Also nice for when I use Zoxide to CD into a deep nested directory. I quickly found out unless you manually CD each hop, the different parent directories aren't added to your Zoxide DB. (I have come across snippits to recursively CD into all directories in a path to "prepopulate" Zoxide).
I made this to jump directly from say `/foo/bar/batz/abc/123` to `/foo/bar/batz`.
#!/bin/bash
# SSH to remote system and change into same (current) directory
DIR=$(pwd)
ssh -t $1 "cd $DIR; bash -l -i" alias ..="cd .."
alias ...="cd ../.."
alias ....="cd ../../.."
The "Unix Power Tools" book is an excellent source for Unix and shell usage tricks
I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been getting pretty creative with it, and at this point have a well polished setup that i can give a shitty sentence on a problem, not only does it understand the task, but theres a full ticket->branch->work->pr review->ready comment flow that it uses. My team also uses ai but they havent quite wrapped their head on ways to really work with it. I have built and shared a number of helpful things with the team to try and help them grow. One such thing was a doc i had my ai instance write, based on how ive been using my setup. This alone has started to get the rest of the team up to where i am.
My team doesnt share the same types of things i do, but they still share helpful things.
Call it what you will; I think if youre not helping your team grow by providing insights and helpful things, then youre not the kind of person i want to work with.
One is actually helping and the other is making yourself more visible to mgmt for promotions.
Most senior engineers I've worked with have forgotten all these tricks, and they actively tell you that while you should try to get better at these things, career gains lie elsewhere. Focus on things with higher impact.
Share knowledge? I don't think anyone here is arguing against that in any way (or conversely arguing for hoarding knowledge).
The concern, one I share, is where the sharing has to happen publicly "every day" - so no matter how trivial, useless, niche, overly-specific the tip is (whatever, the list isn't exclusive), someone shares it.
That's the part that's not sharing knowledge for the benefit of others, but rather self-serving. I might even go so far as to say self-serving doesn't even need to be selfish; the person might genuinely believe they're doing good, but even there, self-serving.
TLDR: Share your knowledge, don't make sharing something every day, even when you don't have something valuable to share, your target.
PS - if this note irks anyone (are routine maxxers a thing?), make the goal to learn something every day, then share where appropriate.
Offering to teach someone something proactively? Sure, go ahead.
Sharing stuff freely when asked and arming someone with the tools to investigate further? Amazing!
Treating a public channel like ye olde facebok wall? Mildly annoying.
Every team/department/org/whatever should have channels everyone should subscribe to, and channels individuals set up that are optional for everyone. The appropriate way to handle this is for the OP to write a few tips once in a while in the public channel, and if people seem to like it, announce that all future tips will be in that channel.
"Oh, yeah, I know a cool trick, but y'all have to wait until tomorrow to find out what it is."
"Look! It's a way to evaluate SQL expressions with a select with a from! Oh, you already knew about it?"
I have nothing against sharing knowledge, especially when seeing someone else do something that can be done better. But just leaving daily breadcrumbs to remind people you're the guy that teaches random trivia feels like attention seeking.
I see it more as: every day they will go on the slack channel and pause, wondering "Is there a neat trick I've learned or used recently?" then they share it. It's like a ritual to remember that you can share things because it's easy to forget other people don't work the same way you do. Writing it all at once is difficult (you have to remember a lot of stuff at once) and it tends to go unread.
I also think every single day is a stretch, but it's nice to pause once in a while to think about how you could help other people with something you've learned.
Both a centralized repository AND a daily message, especially for new employees, would be ideal, imo!
Normalize chatting and sharing stuff in slack!
Annoyance is a clue; not about them, but about you.
What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.
Sorry for the "personal attack" but my point stands, you may not think of yourself as a jerk, but I saw your comment and thought "this guy imagining himself being annoyed at a coworker for a daily message with a helpful tip might be more of a jerk than he realizes". As a jerk myself I judged myself qualified to make that assessment and commented accordingly.
>I shared a trick on slack every day with the engineering team
If anything, I wish I had paid a lot more attention to this in the early days and made a nicer shell environment full of my own utilities, as I felt my skills just kind of slowly erode over the years with each migration. Make a nice little nest for yourself and curate those tools as your own (text) UI.