Earlier quoted context omitted.
Slimzsh[1] is a very nice default configuration. Just a slim prompt, fast-syntax-highlighting and some vanilla settings. I keep a personal fork with a few added plugins (most notably zsh-autosuggestions and ssh-agent). No need for a plugin manager. oh-my-zsh is way too bloated. But it's a nice repo if you're looking for plugins and aliases. [1]: https://github.com/changs/slimzsh
The popularity of OMZ with the performance issues and update nags really makes me wonder if people even notice or care about those two things.
The fish shell is amazing
251–260 of 302 posts
Re: The fish shell is amazing
#252Earlier quoted context omitted.
PowerShell is definitely way more capable a scripting language, but it pales in comparison to Fish when it comes to speed, ease, and pleasantness of interactive use. There's a new generation of shells on the rise which look up to both Fish and PowerShell as models of different virtues they want to embody. A lot of them are already usable, and some day a few of them will be killer apps for developers and sysadmins
Nothing is speedier, easier, or more interactive than Get-Help in Powershell. https://docs.microsoft.com/en-us/powershell/module/microsoft... Using other shells is like living in the stone age. I don't know why people would do that to themselves.
Re: The fish shell is amazing
#253Earlier quoted context omitted.
I do not think that there are many GNUisms in bash, even if indeed there are a few optional syntax variants that should be avoided for compatibility with other shells. In any case I am not aware of any GNUism that is actually useful in scripts, so taking care to not use any syntax variant specific to bash is not a problem. All the important bash features that are not POSIX are not GNUisms, but they are: 1. The 50% of…
To the best of my knowledge, Bash’s parameter expansion syntax[1] is entirely an original, non-POSIX GNUism. It’s extremely common and useful in scripting. And that’s just one small example. [1]: https://www.gnu.org/software/bash/manual/html_node/Shell-Par...
1. expansions introduced by the Bourne shell in 1979
2. expansions added by the Korn shell in 1988 (e.g. ${parameter#word} and ${parameter%word})
3. expansions added by the Korn shell in 1993 (e.g. ${parameter:offset:length} and ${parameter/pattern/string})
There are no parameter expansions that have been introduced by bash.
I agree that the parameter expansions introduced by ksh93 are extremely useful in scripts.
The fact that they are not compliant with POSIX is a good reason to ignore POSIX compliance.
The POSIX compliant way is to use sed for substitutions and awk for substrings (even expr is not POSIX compliant), which results in much longer expressions in which it is easy to make mistakes, and in slower scripts, because external processes must be executed even for simple string expressions.
Re: The fish shell is amazing
#254Earlier quoted context omitted.
> I moved from bash => zsh => fish Did the same, but moved on. Now it is: bash => zsh => fish => nu
What did you prefer about nu?
Re: The fish shell is amazing
#255Earlier quoted context omitted.
> Then you have to learn two languages. Why would I need do to that? > But I write complex commands in the shell a lot ... It's not rare that I write commands that are more than 5 lines long. Ah, well, yeah, in that case, you might wanna stick to ZSH. I don't write complex commands on the shell. If it's more than 1 line long, I will make it a script. Multiple lines of commands with, or without, backward slash separat…
For what it’s worth, as another long line she’ll user, I actually do write those in some combination of the terminal and C-x C-e bringing up my nvim.
Re: The fish shell is amazing
#256I really love fish and the philosophy behind it, especially the "configurability is the root of all evil" attitude. Makes for a well though out software that is a true pleasure to use.
Re: The fish shell is amazing
#257Earlier quoted context omitted.
The best reason to choose fish over zsh is that everything works so well out of the box that you stop messing with it. I haven’t tweaked my shell config in 7 or 8 months now. This is a different mindset from the giant zsh configs, “plugin managers” and other junk that is wholly irrelevant to using the shell. You’d think that fish incorporating a lot of functionality that zsh has would manifest as bloating fish, but,…
Another issue with zsh plugins is that they are incredibly slow. Oh-my-zsh makes every terminal feel like it’s running on another machine over ssh
Re: The fish shell is amazing
#258Earlier quoted context omitted.
I don't get why people expect POSIX compliance from fish. Your interactive shell and your scripting shell can be, should be, and often are, different. I use bash as my default user shell, fish as the default shell of my terminal emulator, and I write scripts for both POSIX sh (dash and busybox ash) and bash. I end up using three different shells with different purposes. Sure, I could use zsh both as an interactive an…
I am a fish shell user, but for me the biggest drawback is that a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish`.
such as?
Re: The fish shell is amazing
#259Earlier quoted context omitted.
Ideally you do want them to be the same, so that the skill of using one reinforces the skill of using the other, and you can begin to shape scripts out of your shell history. Output redirection doesn't work right with Fish functions, which makes them unusable in certain kinds of scripts. Aside from that, though, Fish is perfectly pleasant for simple scripting. I use Fish for simple stuff and PowerShell for anything s…
Agreed. I liked fish last time I tried it (probably over a decade ago), but bash scripting is what I'm familiar with and it's just so convenient in day-to-day usage to be able to throw out one-liners for mundane things and then have them permanently searchable in my history.
Re: The fish shell is amazing
#260Earlier quoted context omitted.
If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. I know what you mean, though. Most shell languages don't feel like flexible, expressive programming languages in the way that they ought to and could. As you may know, there are some new shells/languages that are trying to bridge the gap in a way that still leaves the shell…
> If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. Perl's actually pretty good here; I'm pretty new to it, but it's generally what I reach for when I feel like a bash script has gotten just a bit too complicated.
If all you're doing is `a | b | c | d` then use bash but if you're pulling stuff out of the middle in a loop, yeah, might want to use a real language.