Hacker News Reader

Comment by boffinAudio | Hacker News Reader

I so rarely see my (oft-repeated) favourite BASH script hack - commenting ones command lines:

    $ mv -n ~/Desktop/*.pdf ~/Documents/PDF_Archive/  #pdfsync

This command, which sweeps all the PDF files off my Desktop into a PDF Archive, is easily recalled with the key-combo Ctrl-R "pdfsync" - this is very convenient because it doesn't require me to add a custom shell script anywhere, in any particular path, and can also be used to refer to combinations of commands, for example:

    $ for i in some_collection_of_git_repos/ ; do ; pushd . ; cd $i ; git fetch --all ; popd ; done #refreshgits

Ctrl-R "refreshgits", and voila: all of the repos I'm interested in get a full automatic refresh ..

Command commenting is my favourite trick to teach ops newbies, too .. right after they learn about just how important "history > some_history.txt #historylog" is as a command, as well ..

View on HN

At this point why not create an alias or function in bashrc? Then is also portable to other setups?

Although I do have plenty of real aliases, functions, and even whole shell scripts, keeping something as a spelled out command in history actually can be better in at least two ways: It's more flexible, and it's self-documenting.

Worked example: Sometimes I like to fall asleep listening to an audiobook or podcast. So I open termux on my phone, and run something like:

    sleep 10 && date && mpv --volume=90 --speed=1.2 $AUDIO_FILE ; date

which gives me a moment to settle in before it starts playing, leaves the start/end time on the screen so I have a rough idea when I fell asleep, and presets the audio how I like it. Now of course I could extract that into a shell function like `mpv-tweaked` or whatever, but that would either hardcode all the numbers there, or require me to implement arguments, and even if I did they wouldn't be as visible. By just pulling it up with ctrl-r and editing as needed, I have all the options visible right there and every one of them is obviously labeled.

Making functions takes substantially more effort (and has some advantages).

Easiest way I know of:

Ctrl+R to start reverse search

Type enough to locate last command

Ctrl+X, Ctrl+E to launch command in $EDITOR

Wrap in fn() {} or alias

Save as, or append to some file, e.g. in Vim `:w >> ~/.aliases`

.. promptly forget that you did this, or where you put the file containing the custom shell function, etc.

Ctrl-R serves a mnemonic purpose as well.. it helps you document your workflow and processes at the shell, and not hidden in some file somewhere.

Yeah if you can't locate code you wrote in your own home directory, I dunno what to tell you mate. I'm not here to tell you not to continue your love affair with reverse history search. Do what works for you. All I did was share the easiest way I know to persist a history item as a fn or alias.

Where does it live? In a .bashrc I have to maintain? The point is, not having to create an alias or function, because the tool lives in history.

None of these are that complicated that they deserve a dedicated shell script and chmod'ing, or presence in a cloneable repo, etc.

Tools that live in history are fine and good ... until they roll out of history.

Mind: I rely on shell history all the time, and I'm noting, admiring, and planning to adopt your commenting hack, it's ingenious.

But once a particular shell hack / one-liner / function has become sufficiently useful and proven, I'll typically add it to a shell function file (~/.bash_functions, sourced from ~/.bash_profile or ~/.bashrc), or my scripts directory (typically ~/.bin/ for personal hacks, /usr/local/bin/ if it's something I'll use from multiple accounts. Also park that under git and back it up / archive it somewhere or several somewheres.

Atuin should help with large histories; https://atuin.sh/

Graduating specific oneliners into functions/scripts is also a good chance to clean them up a bit, but it's a balance that's hard to strike - too many aliases and scripts, and you quickly forget they exist :-)

Thats fine, but do you understand the point that, by putting these utilities into a shell script, you're negating the ability to search for common commands through history, and now also need to load up your working memory with the name of the script, where it's located and so on?

I do put bigger/heftier utility functions into shell scripts - its just that I, more often than not, forget where they are and have to go searching. But with Ctrl-R, the flow does not get interrupted.

Anyway, not arguing for/against either technique - they are both appropriate when needed.

Commands which I make frequent use of as shell scripts or functions ... are also in my shell history, interestingly enough.

They also benefit by the further mnemonic / rediscovery trigger of existing in my local ~/.bin/ or ~/.bash_functions directory and/or file(s).

If you're not worried about multiple machines, then appending to bashrc is low effort. If you are, then jumping to version controlling at least part of your bashrc (just source it from the main file) is probably the easiest solution anyways. I agree that all of this is more effort than history, but only barely and I think it's worth it for common things that are suited to becoming functions or such

Note that you can use git-for-each-repo(1) to run git-fetch on a list of repos. You can define the list in your Git config and use that.

Thanks, yes I do know about that, but sometimes I want to have a bit more control over the for .. do .. end loop .. and also I'm rather a bit more of a fan of using the directory structure to remember repo's than a git config file somewhere, you know?

That's a good one! I didn't know the comments also showed up in reverse search. TIL!

Reply on news.ycombinator.com