1. 41
  1.  

  2. 15

    No history searching is supercharged without fzf: https://github.com/junegunn/fzf

    1. 2

      How do you deal with the crappy fuzzy matching of fzf? like https://github.com/junegunn/fzf/issues/1823

      1. 1

        I haven’t had any problems with it, I wouldn’t call it crappy either. What completion system (in any software) do you know of that solves the issue you described there? I don’t personally know of any autocomplete that works on editing distance instead of something like /f.*o.*o/.

        1. 1

          Hm, ok. I didn’t investigate further. I still use fzf for history search just not for cd anymore.

      2. 1
      3. 8

        I see this kind of stuff and remember why I switched to fish. Simple and powerful.

        1. 3

          I used to use fish. But I write a ton of bash scripts so I’m extremely familiar with that syntax. I slowly became more and more irritated having to learn and remember how to do things in fish that I could quickly do off the top of my head in bash. And I mean ad hoc stuff directly in my shell session—obviously fish doesn’t stop you from saving bash scripts to files.

          Eventually I settled for zsh with a few fish-inspired plugins. But wow, fish is truly inspired. Anyone who doesn’t have any particular attachment to bashisms should switch to fish literally right now.

          1. 1

            How easy is it to switch to fish from bash? Is it mostly compatible with bash?

            1. 7

              It’s entirely incompatible and takes some time to setup and relearn. It’s not bad though.

              1. 2

                I switched from fish to zsh. Depending on what features you want it might requite some effort.

                1. 1

                  I tried fish, liked some of the features, such as autocompletion, but found the incompatibility awkward, so I ended up switching to zsh with a few plugins such as autosuggestions. I’ve basically stuck with the same zsh config for years now.

                2. 2

                  Trivial. Just fire up fish and run your commands like you normally would. The differences are mostly things like for circles and other shell built ins. How often do you use these on an interactive session?

                  There is absolutely nothing forcing you to stop targetting bash in your shell scripting. I’m fact fish documentation is clear about its intent not being a script interpreter but focusing on interactive shell usability.

              2. 6

                Something I love to add to ~/.inputrc is the following:

                "\e[A": history-search-backward
                "\e[B": history-search-forward
                

                This gives forward and reverse search (Ctrl+R and Ctrl+S) on your up and down arrow keys, so you can quickly search through history with prefixes.

                1. 4

                  This is the single greatest usability improvement to the terminal that I’ve found. It changed my entire experience when I found it a few years ago. This and the history storage changes are the first thing I get new users to add.

                2. 5

                  There is one tip that is always forgotten in these discussions: comments!

                  You can add a comment to any command when running it so you can easily find it back

                  $ super-comlex --command --lots-of-flags 42 # production deployment
                  

                  Now you can search for “production deployment” in your history

                  1. 2

                    I have history limit of 10000 and it gets overwritten often (thanks to writing books on cli). I know I can increase the limit, but that’ll just slow down my rickety old desktop.

                    So, I have this alias to save the last command:

                    alias sl='fc -ln -1 | sed "s/^\s*//" >> ~/.saved_cmds.txt'
                    

                    It is easier to browse this file too, as it is less than 100 lines.

                  2. 4

                    I cannot line without this reverse search replacement: https://github.com/dvorka/hstr Recommend.

                    1. 2

                      This is great, I had picked some of these tricks up from stack overflow answers but I appreciate the comprehensive post!

                      One question: does anyone else ever do a “transplant” of old bash history into a fresh machine? I find it comforting to still be able to reverse search over old commands.

                      1. 1

                        I’m wondering the same thing. I’ve thought about uploading to s3 after every command or session too….

                      2. 2

                        Unless I’m mistaken, OpenBSD’s ksh writes and loads each command from history the way you implemented it here, it’s just a pity they don’t have all the completion options that bash has to offer.

                        1. 3

                          OpenBSD’s ksh completion is pretty hackable:

                          https://deftly.net/posts/2017-05-01-openbsd-ksh-tab-complete.html

                          What makes ksh unusable for me is it’s inability to split long commands into several lines.

                          1. 2

                            Cool, I didn’t know that!

                            What makes ksh unusable for me is it’s inability to split long commands into several lines.

                            That’s one of the most visible things I do like about it ^^

                        2. 2

                          Another superchanging direction may be the one taken by resh. I would’ve often found it useful to be able to find out when exactly I ran a command, how long it took, what parameters I used. Maybe a query to cluster duration by flags used and exit code – sometimes things become slower for no apparent reason and it helps if you can get some historical data. Also, context, of course.

                          It’s nowhere near feature-complete yet, but I’m already finding it useful.

                          1. 2

                            I’ve had these settings, more or less, for the past couple of decades - the one thing I have that they don’t is an easy way to search history

                            function hgrep(){
                              history | grep $@
                              # grep "$@" "$HISTFILE" # alternative without line numbers
                            }
                            
                            1. 4

                              If your history is large, history | grep can be quite slow. I’ve resorted to the second option you mention, because it’s quite faster.

                            2. 1

                              I’ve not used it in anger yet, but I quite like the idea of search history that uses your current working directory for additional context: https://github.com/cantino/mcfly

                              1. 1

                                Maybe not directly related but the discussion about commenting and recovering previous commands covers some of the same use-cases: tldr.

                                The idea is to be available like a man page but to give you common invocations instead.

                                Makes the command line better in my opinion.