Small Programming Tricks
37 points by bugsmith
37 points by bugsmith
Picking up on these little nuggets was always one of my favorite things about pair programming.
I'll share one that I don't see get talked about much but I use it daily. fpp
rg pancakes | fpp
That will parse all the file paths from the output and allow you open one or more in your editor.
I use it all the time with git status to quickly open all the files I'm working on.
It is a Facebook project, so if anyone has alternatives tools I would be open to trying something else.
Kind of similar -- if you use grep -n to add line numbers:
$ grep -n visit_try */*.py | tee _tmp/z
mycpp/control_flow_pass.py:435: def oils_visit_try_stmt(self, o: 'mypy.nodes.TryStmt') -> None:
mycpp/cppgen_pass.py:2850: def oils_visit_try_stmt(self, o: 'mypy.nodes.TryStmt') -> None:
Then open _tmp/z in Vim, and hit gF over any line, then it will jump directly to that file and line.
It works with lint tools and compilers too, because they all tend to output this "microformat" of filename:line123
I have no idea how it works, but many years ago I stumbled upon this:
vim -q <(grep -n visit_try */*.py)
and then use :cn to move from match to match. The help docs call it an "errorfile" but I think of it as my grep navigator.
Nice. I'd love to have something similar that would instead append the selected files as arguments to the command I'm currently constructing.
$ rg pancakes
(...)
$ ./add-maple-syrup [I press a shortcut here and select files from the previous output]
Kind of similar to fpp's command mode but integrated with the shell so I keep other shell features like the history.
I had been using my own similar tool (Python script), but instead it looks at the clipboard for looks-like-a-file. I'm still very much using my mouse, so this way I can visually control what I want to open.
Another benefit is that this works everywhere, even outside the terminal, or after a slow command I can decide if I want to open the output or not without having to run it again with a pipe.
you don't need find but that's because you should install fd instead (:
I didn’t know you could get ** in bash! I’ll have to try that tomorrow. The part on applying log10 to metrics went a bit over my head, but this stats stackoverflow answer helped a lot:
Log-scale informs on relative changes (multiplicative), while linear-scale informs on absolute changes (additive). When do you use each? When you care about relative changes, use the log-scale; when you care about absolute changes, use linear-scale. This is true for distributions, but also for any quantity or changes in quantities.
I used to give mini-workshops on tips like this and the one I saw get the most adoption, lasting many years down the road, was ctrl-r. It searches history for something you've typed at a prompt before. What makes it so powerful is it works across Bash/ZSH, IPython, erl/iex, Claude Code... just anywhere there's a prompt.
It's been very rewarding to see my colleagues go on to teach it to others.
You probably don’t need find. A lot of find commands can be replaced with globs like **/*.md. Most shells support this out of the box, but with bash, you need to turn this on with shopt -s globstar.
The main problem about using globs that you should be aware of is that then you might be subject to length limits. In bash:
$ getconf ARG_MAX
2097152
Of course, two million bytes suffices for most tasks, but when you reach it, you're out of luck. Hence once I want to recurse into directories, I always avoid globbing.
find is not so bad once you know how it works (my recommendation is to learn how to use -execdir and find ... -print0 | xargs -0 ..., which are the most robust ways to use it that I know).
And when you need something really esoteric, maybe use a full programming language.