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/.
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.
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.
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.
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.
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.
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.
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.
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.
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
No history searching is supercharged without fzf: https://github.com/junegunn/fzf
How do you deal with the crappy fuzzy matching of fzf? like https://github.com/junegunn/fzf/issues/1823
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/.Hm, ok. I didn’t investigate further. I still use fzf for history search just not for cd anymore.
I prefer hstr: https://github.com/dvorka/hstr
I see this kind of stuff and remember why I switched to fish. Simple and powerful.
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.
How easy is it to switch to fish from bash? Is it mostly compatible with bash?
It’s entirely incompatible and takes some time to setup and relearn. It’s not bad though.
I switched from fish to zsh. Depending on what features you want it might requite some effort.
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.
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.
Something I love to add to
~/.inputrcis the following:This gives forward and reverse search (
Ctrl+RandCtrl+S) on your up and down arrow keys, so you can quickly search through history with prefixes.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.
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
Now you can search for “production deployment” in your history
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:
It is easier to browse this file too, as it is less than 100 lines.
I cannot line without this reverse search replacement: https://github.com/dvorka/hstr Recommend.
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.
I’m wondering the same thing. I’ve thought about uploading to s3 after every command or session too….
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.
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.
Cool, I didn’t know that!
That’s one of the most visible things I do like about it ^^
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.
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
If your history is large,
history | grepcan be quite slow. I’ve resorted to the second option you mention, because it’s quite faster.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
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.