3 ms·

I've always found interactive history UI to be difficult to work with beyond the most trivial cases. Instead, I'd always find myself typing "history | grep ...

by curtis 14y ago

I've always found interactive history UI to be difficult to work with beyond the most trivial cases. Instead, I'd always find myself typing "history | grep ..." over and over again. Eventually I wrote an improved history command with built-in filtering: http://curtisb.posthaven.com/a-better-history-command http://curtisb.posthaven.com/a-better-history-command

ajross 14y ago
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.
- mdpye 14y ago
  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.
  - ajross 14y ago
    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.
- dllthomas 14y ago
  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).
  - ajross 14y ago
    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?
    - dllthomas 14y ago
      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.
      - akkartik 14y ago
        How do you persist these scripts across sessions?
        dllthomas 14y ago
        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.
- catenate 14y ago
  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.
- npsimons 14y ago
  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.

by curtis 14y ago

ajross 14y ago

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.

mdpye 14y ago
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.
- ajross 14y ago
  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.
dllthomas 14y ago
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).
- ajross 14y ago
  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?
  - dllthomas 14y ago
    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.
    - akkartik 14y ago
      How do you persist these scripts across sessions?
      - dllthomas 14y ago
        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.
catenate 14y ago
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.
npsimons 14y ago
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.