That's pretty big news for a more POSIX-like behaviour!
Just use fish and use shebangs `#!/bin/sh` (which should be in your scripts anyways) and you can keep writing/running POSIX scripts all day. I think it's the best option until nushell[0] is ready.
As an added bonus now that you don't use bash interactively you can substitute dash[1] and increase the speed of most POSIX scripts, win-win.
I'd also recommend zoxide[2], i feel like it's one more must have no matter what you do in the shell.
[0]: https://github.com/nushell/nushell [1]: http://gondor.apana.org.au/~herbert/dash/ [2]: https://github.com/ajeetdsouza/zoxide
However, since using Github Copilot I'm expecting a bit smarter suggestions. I wonder if anyone has tried putting a GPT-3 like engine behind command line autocomplete suggestions. Or maybe the Copilot team offer a sort of API for this.
I remember that I was able to replicate this last year, not 100% sure why I'm not using it daily tho. :D
One thing to note, the limited waitinglist he talks about in the video is done, and now you can sign up and "pay" for ~NLP~...ahem CLP tokens as OpenAI calls them
- Long-suffering bash user
The defaults of fish are great and common tasks are simple. The for loop syntax was so intuitive I got it right the first time without checking Google (which I have to do every time I write a bash for loop).
Not much more to say I think.
These days, I'm playing with xonsh[0]. If I don't use the "standart" shell bash, I might as well use something that's integrated with Python.
Fully agree. It feels like fish is the Apple of shells, in that regard. Unless you really love to tinker with your shell, the great defaults and great UX make it really easy to recommend.
Fish is nice in many ways, but it kinda lives up to its "A command line for the 90's" slogan. It's better than what came before it, but I'm not sure it's better enough. Using a non-POSIX shell can feel like death by 1000 cuts sometimes, and I wasn't sure the benefits of Fish were worth the cost. Also, scripting feels like a bit of an afterthought in Fish and that's a very important part of a shell to me.
These days I'm feeling optimistic about Nushell; it's not quite ready for most people to use as a daily driver, but it's getting there and it has a much stronger value proposition than Fish.
Also, for some reason I never come across issues with it being non-posix. Maybe I copy paste less from online then other folks.
Then I tried switching to zsh with oh-my-zsh and all that. 42 million tunable bits and I still didn't get it to my liking.
Then I found Fish and 95% of the stuff was good enough out of the box. The only things I've really added was Starship[0] as a prompt - again good enough with pretty much zero configuration and fzf[1] for history search.
Now I use it everywhere, synced via Homeshick[2]
I still use bash to write shell scripts that aren't long enough to be converted to Python though.
[0] https://starship.rs [1] https://github.com/jethrokuan/fzf [2] https://github.com/andsens/homeshick
Using just plain bash seems so foreign to me. Having no FZF command history search or intelligent auto-completion would kill my productivity. I'd say it's as essential to my workflow as tmux.
The only major downside of fish, in my experience, is the incompatibility with bash scripts. Sometimes it's a hassle to rewrite those to be fish-compliant. But honestly, this is something I run into once in a blue moon. On the flip side, the simple fish syntax really encourages me to write my own fish functions, whereas with bash I was always dreading writing bash scripts.
Personally, I can fully recommend fish. In my experience, switching to it is not even painful at all, not like vim which took me quite some dedication to get through the learning curve (switched from Sublime Text).
In December just gone I gave up on macOS after 17 years and switched to Linux. Thought I’d take the opportunity to try a new shell and went for fish (though I still use bash on certain remote hosts for a variety of reasons).
autocomplete and colours/highlighting are more than enough to keep me using it. I really enjoy them. But…
I don’t yet love how history works. Four months in, I still can’t get used to not having ctrl-r.
I miss the symmetry of `do … done` in loop syntax, finding `for … end` jarring.
The lack of !! really grates sometimes. I was going to say I miss `^x^y` last command modification, but actually I can’t recall trying it since switching.
`VAR=x cmd …` doesn’t seem to work quite how I expect. I have an alias/function to perform SSO login to AWS, which expands to `BROWSER=otherfunc aws sso login` - otherfunc itself expanding to `firefox -P workprofile`. This stubbornly opens a Firefox tab in some random window, regardless of profile - despite otherfunc on its own always working. I did not, IIRC, have this trouble with bash.
I think it's worth getting used to but there are plugins like fzf that implement ctrl-r
> `BROWSER=otherfunc aws sso login`
Aliases/functions are generally not visible in child processes. I guess it worked if the "aws" tool invoked BROWSER via a bash process that either sources aliases from a bashrc, or reads exported functions ("export -f otherfunc"). It would work for fish too if "aws" invoked BROWSER via fish (though fish doesn't need exporting, since functions are also loaded in non-interactive shells).
I recommend that you make otherfunc a script, then it will work everywhere (also with arbitrary wrappers like strace, gdb).
Fish excels as an everyday interactive shell. I never program shell scripts. I write Julia code whenever something equivalent of a shell script is needed. Before that I often used Go.
It's not like fish installs to /bin/sh, nor are /bin/sh scripts executed using fish just because your interactive shell is fish. I guess these are the two misconceptions the common worries are based on?
The fish scripting language is much easier to read and write than bash (for someone that doesn't write many scripts). So for local scripts I use it but for anything shared it's still bash scripts.
The sole reason I was contemplating switching to zsh in regards to POSIX was the fact my shell scripting knowledge is rather shallow and I could perhaps improve it a bit while working on functions I write for personal interactive use.. Needless to say I've written them in fish haha.. If my assumptions are right what I need to master is combining properly the coreutils and the general mentality of piping things from one command to another etc - I could be wrong tho
This shell makes a ton more sense to my brain than the usual bash/zsh/fish rigmarole, it just needs some love. It's older, but basically much smarter.
The last thing I was working on was a way to capture all of stdout, stderr and return code from a single run of a command, for testing purposes, because the OTHER thing es-shell desperately needs is a proper test suite, and being able to assert on all/any of those side-effects (and the return value) is IMHO fundamental to a proper suite. I figured one out for bash https://github.com/pmarreck/tinytestlib but not one for es yet.
Sorry for hijacking your comment
`#! /usr/bin/env zsh`
However the crux of the issue is that a bunch of the neat features are built into default Fish vs being behind plugins in ZSH.
I still think (with sufficient effort), ZSH is the best (and I think configurable to be faster than default Fish with equivalent features), but Fish is the best out of the box experience.
It's consistent and blazing fast, and that's all I ask.
The one thing I can't work out is how to change the cursor to a block, it's a line. No vi-mode or anything, just a nice rectangle. I tried `set fish_cursor_default block` to no avail.
fisher install FabioAntunes/fish-nvm edc/bass
Writing scripts: #!/usr/bin/env bash (or #!/usr/bin/env sh for POSIX-compliance)
Use fish for interactive shell. It's faster than zsh
Zsh seem to have more plugins
I can be believe it’s faster than a poorly configured zsh (which unfortunately is quite common), but would be curious to see actual test results, with things like “input lag”, “time to first prompt”, “command lag”, etc. like is measured with the excellent zsh-bench (https://github.com/romkatv/zsh-bench#what-it-measures)
Exciting to see it inching toward POSIX compatibility
Finally. I should give it a try now.