Live data from Hacker News

The fish shell is amazing

rmpr.xyz

251–260 of 302 posts

Re: The fish shell is amazing

#251
post #72

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.

If you use just a few plugins, it's really not that slow. But if you have a lot more, performance might become a real issue.

Re: The fish shell is amazing

#252
post #102
post #92

Earlier 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.

Loads of shells have an equivalent to Get-Help

Re: The fish shell is amazing

#253

Earlier 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...

No, all the kinds of parameter expansion that exist in bash belong to 3 groups:

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

#254

Earlier 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?

Working with tables of data feels more right, more like programming then the usual shell. I also work quite often with CSV and it's nice to be able to manipulate/filter it like any other data that nu is able to read (just: open file.csv | find "foobar" | select name message).

Re: The fish shell is amazing

#255

Earlier 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.

Right, as I said, writing multiple lines of commands on a shell doesn't really make sense because it's not interactive usage, it's scripting. And scripting should be done using an editor, which is what you're doing by using nvim to write the command.

Re: The fish shell is amazing

#256
post #27

I 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.

Most of it is nice, but declaring global variables with 'set -gx FOO 123" sucks. Same for "abbr --add g git", why can't it be just "abbr g git" or "set-global FOO 123"?

Re: The fish shell is amazing

#257
post #147

Earlier 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

It sounds like oh-my-zsh issue, not Zsh.

Re: The fish shell is amazing

#258
post #248

Earlier 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`.

> ... 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

#259
post #107
post #74

Earlier 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.

Bash scripting and convenient is strange in the same sentence. Bash is an abomination that should not even exist. Like, even thinking about a line of bash code will have 3 bugs.

Re: The fish shell is amazing

#260
post #224

Earlier 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.

Perl definitely is the sweet spot. Even then, I think python with multiprocessing and the pipe class is better than bash in some circumstances.

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.

Post reply on HN