Hacker News Reader

Comment by ajross | Hacker News Reader

It's funny how personal workflows can be. I do the history|grep thing too, but never felt the need to automate it further. It's a relatively rare thing (maybe once a day), used when I know I did something specific in the past but forget a detail or two.

Instead, I generally drop little shell scripts around my work area for specific tasks. Working on iterating a build/install to chase a specific bug? Stuff it into a little script. Writing a find command to munge a bunch of files with xargs or -exec or whatnot and realize I'm into the third line or editting? Stop and echo it into a file, then finish it in emacs.

The idea of doing all that junk and then relying on the bash history file (instead of, y'know, the actual filesystem) to store it for me seems weird.

View on HN

Acme has an idea of guide files in each directory which store commands you commonly use in that directory. Acme maps a mouse button to "send this text to sh", so you can edit a command in the guide file, highlight it with a sweep of the mouse while holding down the left button, then release the left button and middle-click to run it in the context of the current directory. Over the years this mechanism has greatly improved my retention and usage of interesting and powerful shell commands, and decreased to near zero the amount of time it takes to construct the command and the number of errors I make while doing so.

I use screens and session variables to manage context, so scripts don't need to be "around my work area" but rather in the appropriate ~/.context/$SESSION/bin directory (or ~/bin if sufficiently general).

Again, personal taste leads me to say "yuck" to this one. You don't think that the appropriate spot to do an ad-hoc build integration is the source directory? You'd rather put it somewhere that has to do with the window into which you're typing (which for obvious reasons won't survive a reboot or copy) and not a place that corresponds to what you're actually doing?

Ah, if something's particularly specific to a directory subtree, rather than a particular context/task, I'll drop it in the tree sometimes, for sure. But my contexts very much correspond to what I'm actually doing (and my prompt includes the session), and so ~/.context/$SESSION/bin is "a place that corresponds to what [I'm] actually doing".

Which is not to take away from your "it comes down to personal preference" by any means - just trying to make mine a bit clearer.

How do you persist these scripts across sessions?

I'm not sure just what you mean, but to try to answer: $SESSION contains a meaningful context name, not a nonce string. Stuff in ~/.contexts/$SESSION sticks around unless I manually remove it (I also store context specific history and config files there). If I need to access a script from another context, I can just give the full path - winds up working a little bit like namespaces.

It's funny how personal workflows can be.

Very much so; much like the GP, I would "history | grep" and even had it aliased to 'hg' (which is one of the reasons I don't like Mercurial, just to start another flame war), but then I was reminded of C-r, which I should have known better (as an Emacs user (that's two flamewars . . . )), but oddly hadn't been using as I was just too lazy to really learn bash in depth.

Ctrl-x e opens the current line in your $EDITOR, smoother than echoing, especially when there are pipes involved. Save it out as a script from there if you like.

It's C-x C-e in my bash, fwiw. And I tried getting used to this but it breaks locality by dropping the new file into /tmp instead of $PWD. Quoting a line isn't really that hard, or you can always cut and paste with the mouse.

Reply on news.ycombinator.com