But seems to want us to replace the old reliable shell with it (Or this is what I understand). I see a lot of people reinventing the wheel in Linux and trying to appeal the new users. What you have in the end is normally worse than the standard ones. Is just dissecting Linux in a lot of smaller particles and smaller rooms.
So thanks, but not thanks. Not to me.
Wouldn't be much more practical to use all of those talent and ideas to help to improve the extant bash shell instead?
There are lots of "old reliable shells" that are POSIX incompatible. (t)csh[1] is the first family that comes to mind.
The EEE analogy is more applicable to GNU Bash anyways: it extended the POSIX sh baseline with a bunch of GNUisms that a lot of "POSIX" sh scripts now unintentionally use.
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 the new ksh 1988 features that have not been included in the POSIX shell, e.g. condition testing "[[ ... ]]" and arithmetic testing "(( ... ))".
2. All the new features added by ksh 1993, none of which have been included in POSIX, e.g. "for (( ... ))" and the extra parameter expansions that replace the most common invocations of sed or awk.
3. The brace expansion from csh
4. The extended brace expansion forms added by zsh (which generate arithmetic progressions and are usually preferable to "for ((...))")
Attempting to write POSIX-compliant scripts in 2021, i.e. not using these extra ksh/csh/zsh features provided by bash, is a huge mistake in my opinion, because without these features any non-trivial script becomes much longer and much more error-prone.
The Google recommended style for shell scripts (https://google.github.io/styleguide/shellguide.html), which is based on using all bash features, is pretty decent. It is far less work to ensure that bash or ksh/zsh exists on any target system than to maintain any obsolete POSIX-compliant scripts (which are stuck to the 1979 Bourne shell features + only half of what ksh 1988 has added).
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.
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.
There are a lot of uses for "@", most of which come from Bourne sh or from ksh.
I assume that you refer to the "${PARAMETER@OPERATOR}" type of parameter expansion, which is mostly used to either replace invocations of tr for character conversions or to provide quoted strings.
You are right that this kind of parameter expansion is specific to bash and I was wrong when I have said that there are no bash specific parameter expansions. "${PARAMETER@OPERATOR}" is the only exception that was introduced by bash and which has not been taken from the Bourne or Korn shells.
I have forgotten about it, because I do not use it, precisely because it is the parameter expansion variant that is provided only by bash.
> Wouldn't be much more practical to use all of those talent and ideas to help to improve the extant bash shell instead?
Yeah, good luck with that.
It's a garbage pile of code that creates an interpreter with piles upon piles of undefined behavior that random scripts out there in the world rely on.
I don't even think it was a working CI setup.
I'd be super glad to be proven wrong, maybe things have changed in the meantime.
I used fish for a couple of years and really liked it. But I recently learned that I can configure ZSH to have all of the same auto-complete and plugins that I loved from fish. Now I have all of the creature comforts I like, with POSIX compliance
I found that while fish has better syntax than bash for most things, the hassles with incompatibility or unexpected behavior brought me much more trouble than BASH's syntax ever has
POSIX compliance has never brought me any issues, if I want bash syntax I just use `bash -c COMMAND`.
You can invoke bash scripts with `bash SCRIPT` or just add the bash shebang `#!/bin/bash` to the top of your script, set the executable bit and invoke directly.
Bass has never worked for me, in any scenario. I'm curious to see how you use it. I have never successfully been able to feed it any bash script. At this point I suspect I'm either holding it wrong or it is a thing that is invoked as a thing that works without ever being used in earnest.
bass works for things you're meant to source. If the script is not meant to be sourced, just run bash yourscript.sh .
It basically runs the script in bash, diffs the environment, and applies the environment changes to your outer fish shell. I use it for some internal tools, and previously used it for nvm though I moved from nvm to fnm now which has fish support.
If your bash script has a shebang you shouldn’t need bass at all. Fish will read the shebang and just run your script with bash.
The only thing I ever used bass for was this edge case where at work the way we login to AWS is using this Okta AWS integration that prints out a list of export commands.
Since fish isn’t compatible with bash export commands, I just run that command result through bass, which automatically converts them to the fish set -x commands.
If I remember right, I think the reason why the bash script my company made didn’t work is that the export commands that were run in bash weren’t propagated to the underlying fish environment. I was using fish to run a script with a separate shell, so it didn’t affect my environment variables.
Or maybe it was because running exec inside a bash script throws you back into fish which then can’t understand the export command.
I could have definitely done my own thing with sed/awk instead, but I suck at those tools and someone else already implemented the functionality in bass.
(Off the top of my head, I think it was something like that, could be misremembering! And by this comment you might be able to tell that I’m far from an expert on how everything works.)
This shouldn't be an issue! Shell scripts begin with e.g.
#!/usr/bin/env bash
which means the interactive environment is irrelevant. Users of nonstandard shells like fish need to learn a bit of on-the-fly translation if they expect to copy/paste into their terminals, but it isn't too onerous.
That's basically one of the developer setup steps, in addition to running through installing things like jq and yq. Point is, it was a significant enough of a delta (easily fixed) that we ran into compatibility issues with the scripts we wrote.
Interestingly I moved from such a zsh setup to fish a couple of years back. Zsh with add-ons was noticeably slow compared to fish and syncing the config to all the devices I used.
You can get reasonable version control integration from zsh without any kind of wild oh-my-zsh config. Most distributed versions of zsh are compiled with vcs_info enabled.
I moved from bash => zsh => fish. I wanted reasonable features on my shell, and fish was much faster and needed almost no plugins.
The fact that I can write a simple for loop without needing to look up how to do it by far beats the POSIX compatibility, if I need it I can still write a bash script, but when using the shell I don't need to recall where semicolons or `do`, brackets (and how many) go.
Bash has some subtleties around loops that can be frustrating, like the body of your loop _may_ actually be running in a subshell (common when iterating over a file), making it difficult to extract what you want from it.
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).
Not quite a straightforward as nu seams to be, but I used to have ipython as my shell when I did a lot of work with CSV. It’s “not a shell” but includes some shell like functions to make listing dirs and such easier.
I just start scripts in bash for compatibility at the beginning or use scripts that state it, avoid scripting as much as possible, and I spent a lot of wasted time with configuration of zsh to get most of the functionality of fish but never as good. What did you install?
zsh is not POSIX compliant and never had a goal of being POSIX compliant. (Amusingly, I use bash and I can pretty much replace “zsh” in your claim with “bash” and have it apply to my usage-except in this case it would be true :P)
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, IMO the reality is that zsh’s “bloat” is pushed into user configuration and the user is tasked with making it work.
You probably mean powerlevel10k[0], although that's mostly a replacement of powerlevel9k, which is only one of the (theming) plugins that oh-my-zsh commonly handles.
As for a replacement for oh-my-zsh itself, I had good experiences with zgen[1] but the fastest I've found is zim-fw[2] which produces acceptable start times for me[3].
You don't need that much plugins at all. The only plugin that I use is gitstatus, and zsh-syntax-highlight, and both of them are avoidable without loosing features.
Hence, my issue with the "infinitely configurable" idea: once you add plugins to the mix, it feels like responsibility for the end user experience falls on no one, so the users end up shouldering that, and, worse, sometimes develop a Stockholm Syndrome for it.
For example, to me, it is _insane_ that in 2021 async prompts are not a completely solved problem. The shell should provide a mechanism to do so easily, rather than duct-taping thin veneers over syscalls via a scripting language.
Ditch omz and use Prezto with the Powerlevel10k prompt (just change the theme in the zpreztorc file to 'powerlevel10k' and restart your terminal), follow the initial prompts for setup, with "instant prompt" enabled and you'll never go back.
Thank you for this, I had somehow stumbled across powerlevel10k years ago on my "fooling around" laptop and liked it but couldn't remember how I'd gotten there. Long time zsh user here, just last week started playing with oh-my-zsh to integrate into my main system's shell environment.
> 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've found that sometimes the opposite can be true (in a good way!). At one workplace, I introduced Fish to some fellow developers who until then mostly saw using the command line as a strange, difficult, and unpleasant part of their jobs.
Once I got them started with Fish, they were happy enough with default interactive behaviors, convenient documentation, and simple scripting syntax that it encouraged them to do a little more scripting, and eventually to customize some of the aesthetic stuff by writing custom prompts!
> The best reason to choose fish over zsh is that everything works so well out of the box that you stop messing with it.
This is such an incredibly odd perspective to me. I use zsh and have not touched my shell config in years. Messing with configurations to get things working to your liking is a one time thing. I don't even use plugins.
On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible. You are forced to give up and use something else. Your reason to choose fish is only a good reason if you already agree with every minute choice the developers made and refuse to let you adjust.
> On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible.
What do you want to do that isn't possible? I also haven't messed with it in months if not more (fish in my case, not zsh) but years ago I messed with the prompt a lot to get it to my liking. (From a previous zsh config.) It was perfectly possible.
> On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible. You are forced to give up and use something else. Your reason to choose fish is only a good reason if you already agree with every minute choice the developers made and refuse to let you adjust.
Which part of fish makes this impossible? You can tweak the startup, the completions, the key bindings, the prompt, and so on.
Even less ergonomic shells like bash can work very well out of the box if you just train yourself to use them. If you train yourself to use bash without any plugins, you'll be strong on any machine without any config.
I went through a "distro hopping" phase at some point with Linux and ended up settling on a system with very little custom config. It's close to the defaults so I can work very comfortably even in a random server.
Of course this is not ideal. If you have a tool or set of config that you like, then you should use it. I've just found that the human brain can overcome bad UX quite well with a little effort ;)
There are other benefits to your approach. Relatively little time is spent configuring software and it tends to be easier to copy over a handful of simple configuration files than to replicate a complex setup.
What I do on Linux is keep bash with a minimal config, and then have zsh with oh-my-zsh and all the other goodies. I used bash for a long time, so I don't get too confused by context switching.
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 and scripting shell but I don't have the time or willingness to configure it when fish offers a nice out of the box experience. Not to mention that zsh shouldn't be used as a scripting shell in the first place.
> Not to mention that zsh shouldn't be used as a scripting shell in the first place.
Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?
It's more "why not write scripts?" Actually making use of a shell's control structures is code smell until we have far better shells than we currently do. They're optimized for user interaction, not necessarily anything else.
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 well-suited to interactive use. The Oil shell wiki has a great list of them (and Oil is one such shell itself, of course): https://github.com/oilshell/oil/wiki/Alternative-Shells
> 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.
> Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?
I guess there are two reasons
- if the script doesn't need arrays, POSIX sh (dash) scripts will be much faster than bash/zsh scripts
- if you do need arrays, bash is vastly more ubiquitous than any other shell on the planet right now (except POSIX sh). It's installed on almost all Linux distributions by default. I'm not gonna use a ZSH script because I'd have to install ZSH, which seems unnecessary. A good example is tomb, which is a ZSH script for encryption on Linux.
If you're sure that your scripts will always run on macOS, use POSIX sh if you don't need arrays and ZSH if you do need them.
Then you have to learn two languages. And switch from one to another when you need to do some scripting.
I don't write shell scripts a lot, I prefer to write python scripts (that are more maintainable and simple to write). But I write complex commands in the shell a lot, for example I may need to convert a bunch of images from one format to another, just use a for loop with imagemagik directly from the command line, then maybe a regex with sed to rename them, and done. It's not rare that I write commands that are more than 5 lines long.
With all the quirks of POSIX shell scripting languages (well in reality I use zsh that is nicer) they let you hack things together fast, and that makes them powerful.
> 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 separators look ugly and unwieldy to me. A text editor like vim would do a far better job handling those 5 lines instead of an interactive shell.
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.
> Then you have to learn two languages. And switch from one to another when you need to do some scripting.
The more languages you know the more valuable you are. I prefer to only write golang but sometimes that leads to typescript, Makefiles and bash scripting as well.
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`.
For example, Macports puts its installed binaries into /opt/local/bin (and sbin), and the installation process put this into my .profile:
# MacPorts Installer addition on 2016-07-01_at_00:46:04: adding an appropriate PATH variable for use with MacPorts.
export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
# Finished adapting your PATH environment variable for use with MacPorts.
And I had to put the fish equivalent of that into ~/.config/fish/config.fish myself.
Umm, you don't need to define your PATH variable in `config.fish`, not unless you make it your default login and user shell.
You should keep using bash as your default login and user shell, define your environment variables, like PATH, in your `.bashrc`/`.bash_profile` but use fish as the default shell of your terminal emulator. In that case, fish should pick up the PATH from bash.
That addresses only the part of setting up PATH variable. Some init scripts go beyond that and have additional code embedded in them (see sdkman, pyenv). These needs separate init scripts for fish users. Just a cursory look at github issues can show how prevalent this issue is:
Python venv works fine with fish shell for me. But yeah, this is something that'll always be an issue with fish simply because bash is more widely used.
Unlike what some people may think, it's not just about the tool itself but its ecosystem as well.
Same, I used oh-my-zsh, I mucked around and didn't use it for some years, but since re-installing it, I have to say it's one of the most useful and reliable software packages I know of.
I kind of forgot that even use it until I read your comment :)
Sadly this is the exact reason I switched away from it. I couldn't copy/paste in commands from coworkers or use common web projects (I'd have to either search for a fish replacement or convert it myself... Or just launch bash/zsh).
Really nice shell though, I hope it gets more traction.
I used Fish for several years before switching over to nushell a few weeks ago.
Nushell takes the ideas behind Fish even further by incorporating types other than strings and adding more built-in functionality that’s useful for your average command-line user.
I doubt I’ll go back but both are great! Highly recommend Fish and Nushell!
Fish really shines in interactive use, like being able to write fish_vi_key_bindings, and that setting is preserved after restarting fish. Or using funced and funcsave to modify helper scripts, or abbr -s ...
I'm not sure I've ever opened my fish config file, but I'm still able to customize it easily
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
Get-Help is pretty good, but I don't like several things about it:
1. You have to go out of your way to fetch the full help pages on a given PowerShell installation (they're not stored locally by default).
2. Even after you fetch the full help, not all of it is actually included in the Get-Help output (IIRC examples), so you often need to use `Get-Help -Online`, which opens a separate application (browser) and that sucks
3. Inside the terminal, there's little to no special formatting or syntax highlighting, unlike what you get with a good `man` pager
4. Get-Help output (unlike `man` output as configured on most distros) is not paged by default.
`man` could be better, and I don't really vibe with `info`, but Get-Help isn't that great imo. The actual content of the help is quite good, and it's nice that it includes examples, but the same is true of most man pages.
I've found fish to be absolutely wonderful for shell scripting. I can throw together a loop or a function with the sort of confidence I never could have in bash.
Scripting in Fish is great in that even when you're still pretty new to Fish, you almost never have to think much about syntax or worry about quoting/word splitting behavior. It feels a little LISP-y, in a good way.
As another commenter pointed out, while Fish has some nice out-of-the-box features, they’re all achievable in Zsh with a few lines of plugins. And did you know Zsh has a short for loop? Along with fantastic plugins like fzf-tab, I don’t see a reason to use anything else right now.
Though, I’m keeping a very interested eye on Nu shell. They’re doing a lot of stuff right, and I expect it will become a very useful scripting language in its own right even when not used full-time as a shell.
I find it amusing when people are discussing all these new shells and features, yet everytime I see someone letting them know they can do these exact same things in bash, there's absolute silence. It's not the first time I see ble.sh being recommended here with no reactions from the community whatsoever.
As for fish, I've used it for a few weeks. Not having POSIX compatibility and GNU readline shortcuts made work much, much harder.
Ble.sh seems pretty cool. The path hacking it does on readlink doesn't work right and causes the CNF handler to launch on NixOS.
I guess it does the PATH hacking based on whether the system is GNU or not so that it can get `realpath`/`readlink -f`-like behavior even on systems that don't natively have that because they include *BSD coreutils.
That might not behave as expected (and is unnecessary) on my macOS systems, either, since I like to keep GNU coreutils (with no `g` prefixes on the executable names) on my PATH there (heresy, I know).
It's also noticeably slower, to the point that there's a bit of jitter as I type.
It's pretty cool, though. If it's any better after I patch the readlink PATH hacking out, maybe I'll configure it for bash on my systems.
But I think it's quite good for scripting. You can call any system command as easily as in bash while being able to use variables for not just strings. I'd never use it as interactive shell, of course :]
Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
Yeah, I agree that PowerShell is great for scripting. I don't do that much scripting on my personal Linux systems that really calls for PowerShell, but I like using PowerShell for hitting HTTP APIs or processing structured data at work.
> Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
Hahahaha! Oof.
It's more work, but when I use PowerShell, I try to use pure PowerShell, both for aesthetic reasons (cleanliness, ‘portability’) and just in order to practice and learn more PowerShell APIs along the way.
Zsh has become an indispensable power tool for me. I am interested in other shells (especially PowerShell), but Zsh is now embedded deep in my brain, next to Vim and Python, and I doubt I will ever seriously migrate away.
That said: what do you like about Nu shell specifically?
1. abandonment of POSIX shell syntax. We can do better. I'm happy with Zsh being POSIX-compatible, and that will always be there.
2. a focus on structured data. Nu basically has hierarchical dataframes built-in, along with lots of facilities for their manipulation. There have been a few other attempts at this but the benefits are obvious. Rather than figuring out how to `awk` your way through whatever text output a command generates, command output in Nu is structured and everything can be handled in orthogonal ways.
3. modern conveniences built-in, like syntax highlighting, and AFAIK they want to include features like "do something when you cd into a directory" that we currently need more tools for (i.e. direnv, which I highly recommend!)
4. serious technology. The people behind it are experts and JT has been showing off (https://youtu.be/3o8b_QcrFHc) the engine that enables trivially parallelizable loops. No more need for `xargs`.
5. I hesitate to mention "made in Rust" as a feature, but using a modern language for core infrastructure does matter.
I'll put it this way: Nu shell seems perfectly supportive of my philosophy that a shell is basically a REPL for a computer, and they're taking the ergonomics of an interactive REPL along with the programming language that powers that REPL seriously.
The thing is, there's currently NOTHING GOOD for "shell scripting". Shell sucks (yes it does), so for anything more than very short things I'd rather write Python. But Python sucks for shell-like things, parallelization, it has slow startup, and you also can't do things like put environment variables into your session or change the working directory, so you often wind up writing shims (eg. Broot's br alias - https://dystroy.org/broot/install-br/).
Yes I've looked at Xonsh but maybe the additional syntax is offputting to me. Like, I wouldn't use it as a shell over Zsh (how's Xonsh's fzf support? I don't know, but I know everything's going to support Zsh), and I dunno if I want to use its syntax extensions over just Python. Though It's always on my list of things to re-explore, and maybe it'll click one day. But it being based in Python makes it feel slow (I wrote my prompt in Zig to get it to be fast...)
This is relevant to mention: I wrote a small Python library (https://github.com/kbd/aush) that's basically a DSL for subprocesses, so it tries to make it more convenient to do shell-like things. I find it preferable to shell or Python alone most of the time. Here's an example of its use in my script that creates a new Python project: https://github.com/kbd/setup/blob/master/HOME/bin/create-pyt...
I haven't figured out a convenient way to implement shell piping well with Python's pipe operator, or pass through interactive output directly (so things that "update" the display, like poetry and npm don't behave the same as they do interactively) so it's still .9 status, but it works really well for what it is, and you can always write "regular Python" along with it.
Anyway, Nu seems to be an attempt to put a "real" programming language REPL in my shell, from people who have serious language experience, so I'm hopeful it'll be great.
I appreciate the clarity of your message...
curiously enough all the things that you mention I see them as anti-features of nushell (except the first one)
1. Posix shell is clunky has its limitations but there's nothing really flawed about it. It is nice to have non-posix shells, though; in that I agree with you.
2. I hate hate hate the very concept of dataframes. They seem like a useless over-engineering. Plain tabular data is a perfect, and the columns of a table are always named 1, 2, 3. The whole point of abstraction is that you do not care about the meaning of the columns of your table, and the programs (like the lovely awk) that deal with these columns do not care either. There's nothing more "orthogonal" than that: filters that do not understand the data but can filter it anyway.
3. syntax highlighting is a very personal issue; in my case I prefer my terminal not to look like a christmas tree.
4. xargs is one of my favorite tools (alongside gnu make and gnu parallel) and there's nothing "unserious" about it. The happiest moments in my programming life are when I get to use these tools. Not using xargs sounds like a nightmare!
5. Rust is definitely an anti-feature to me: it's like a language that was built by picking the worst features of many already ugly languages. I would not really care in what language the shell is written, but I'd rather have it written in saner, "unsafe" languages.
I strongly disagree about data frames. I am a data scientist professionally, and I think the data frame is one of the most important programming abstractions I use.
> Posix shell is clunky has its limitations but there's nothing really flawed about it.
I think shellcheck is the best argument against this. POSIX shell is just stuffed to the brim with weird gotchas, places where the obvious way to write something causes subtle bugs down the line.
It's the only programming language I use that feels adversarial, where you have to be paranoid to properly solve simple tasks. (Admittedly some of that is because of the reliance on system programs rather than the shell language itself.)
> It's the only programming language I use that feels adversarial
This may be just that you are not very used to the language. I have the same dreadful feeling (that the language fights against me), even when using languages that I'm reasonably proficient with.
For example, in C++, a simple expression like "y = f(x);" already gives me the chills... Is the () operator overloaded? and the assignement operator? If the object x has size equal to 10GB, and y is supposed to have the same size, how much memory does this operation require? 10GB? 20GB? 30GB? 40GB? each of these completely different answers is perfectly reasonable, depending on extremely delicate details of the implementation.
Garbage-collected languages are even worse, I never know whether they will start a memory reclaiming spree that will halt my program for a few seconds.
Even in python, I have this sort of jump scares a few times per month.
> while Fish has some nice out-of-the-box features, they’re all achievable in Zsh with a few lines of plugins.
The point of fish is that there is no configuration required.
You don't have to learn to configure it, you don't have to be part of "the community" to learn which plugins to use, you'll be able to sit in front of any fish prompt and have it work as expected without having to move dotfiles around.
That's a cool argument for Fish for beginners. When you spend thousands of hours in a shell that doesn't matter as much. I don't see any benefit for someone who has Zsh set up well, but yes you do have to google once how to configure auto-completion and so on.
Probably little for anyone who has any shell “set up well”. Just if they are tired of spending time tweaking things and would rather more capable out of the box experiences so they can benefit from features added to the core shell without hunting for plugins.
I use Fish, however I also use Vim and do the plugin hunt there. I enjoy it, but I’m glad to not be doing it for both my environments.
Comparing the "plugin hunt" between vim and zsh is a bit much. I use three for Zsh, just syntax highlighting, autosuggestions, and fzf-tab. I don't use a Zsh plugin manager.
> The point of fish is that there is no configuration required.
I think it would be more accurate to say that the point of fish is that there is no configuration allowed. If you don't like the out of the box configuration, I would say configuration is still required, but it's unfortunately not available. If you happen to like every single decision the developers made, then I admit having no configuration does mean you end up with a simpler, faster, more maintainable shell.
> If you don't like the out of the box configuration,
Then either decide to like it -- humans are adaptable, this is possible -- or don't use the thing. Both outcomes are acceptable. A hammer doesn't need to have a configurable grip and head and claw in order to be a good tool.
Yes - that's exactly what I said. I'm not sure where you think you disagree. The point of fish is that configuration isn't allowed. I, personally, don't use it.
I think this really shows the two schools of thought, and this is reflected in the attitude towards linux too.
A: Linux is amazing, I can configure everything the exact way I want.
B: Linux sucks, I need to mess around with configurations for hours before I get something usable.
A lot of us just want something that works out of the box with amazing defaults. Others want something that can be tuned to their exact preferences. However, configurability comes with it's own costs too.
Fish isn't that extreme. There's a fair bit of configuration allowed. The devs are just judicious about adding toggles.
You can configure scripting to run at various times, and there are even plugin frameworks for Fish. It just doesn't have toggles for things like language features in the way that ZSH does.
zsh has this absolutely ridiculous case of feature shyness. It has tons of great features, which it goes to great lengths to hide from you for some indecipherable reason.
The reason is to preserve compatibility for everyone's configuration that they carefully built up over decades. It's quite hard to change things to enable some new thing without annoying many users. The last time that was tried was in the '90s and there are still zsh developers around who experienced the fallout. I value the fact that my shell doesn't change on me without warning like many GUI desktop environments.
In recent years the existence of frameworks like oh-my-zsh has contributed further to this situation because it has separated the detailed configuration from the base zsh project. It's a pity omz doesn't enable more really. Many things it does are not really useful unless you take the time to actually learn them. A lot of plugins just define aliases but if you don't know what they are, they just sit there unused.
I'm usually happy to put some effort into configuration upfront as a new user if it buys me the peace of mind that I won't be thrown under the bus later. OTOH, I recall some classmates being unaware that Vim supports syntax highlighting because the version that was installed on our lab computers didn't enable it by default (this was about five years ago), which also seems like a regrettable outcome.
Nice. Yeah it works great. I have an extensive set of git aliases. Yesterday I was merging a branch with `gmn` (`git merge --no-ff`, which is actually an alias to `g mn`, where `g` is an alias to git of course) and it gave me a fuzzy find of my branches through all the aliases.
Edit: also things like `kill`. `kill [tab]` gives you a fuzzy-find list of all your processes so it's way faster to use than ps | grep.
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.
I love that philosophy too. If there's too many knobs to turn I'm going to constantly fiddle with them. The only things in my config.fish are calls to scripts to setup iTerm 2 integration and the Starship prompt.
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"?
I started a new job recently, and I've been thinking about terminals and shells. I love a well configured modern env, but I can't be bothered spending the literal HOURS you need to setup everything... zsh, zsh plugins, fzf, fzf plugins, fd, dot bare, patched fonts, 24 bit terminal color, temrinal color theme, binutils color theme, powerline, diff-so-fancy... I get that the devil is in the details, but come on, can I just have a single "terminal environnement distribution" with sensible defaults and that's it. Something like SpaceMacs/SpaceVim but for all that. I don't want to spend the time configuring and maintaining this wonderful pile of obsolete-and-yet-somehow-still-the-best-we-got technology.
Just synk your dot files with your config and a readme for what you need to install. Getting my shell up on a new computer is very fast because of this approach.
it's not such a trivial thing even if you manage dotfiles because a lot of things still break between different environments, different operating systems, don't work with new releases, rely on some folder structure that changes, etc, it still requires fiddling.
Of course you can get even more involved and manage your dotfiles with ansible or something but the advantage of a tool like fish is that it's almost perfectly usable out of the box. More config files will always increase the chance for things breaking.
I use Powerlevel10k + ohmyzsh + Fira code + and the first google entry to "make zsh like fish". Usually takes me about 10 minutes to get set up in a new environment.
I stopped using patched fonts because of that. And I never felt like 24 bit terminal colors was necessary. You can just install fish and then the fisher plugin manager and then install a theme/prompt plugin.
The default setup is pretty much perfect for what I want. My only additions are fzf for history search, a bunch of aliases and Starship for informative status lines.
I agree with you here. I am like a terminal nomad, I have of course my own computer but there are so many other computers I log in to over the course of my career. They usually have bash and I have learned to just like that. I don't want to maintain one habit for my pet computer, and another when I am a nomad.
Don't forget that if you use #!/bin/sh in POSIX compatible scripts, you can configure /bin/sh to symlink dash shell instead of bash or zsh. Dash will run scripts way faster (up to 4x) because it is less feature blown...
This is the reason, why I try to prevent using bash/zsh exclusive features in my daily use scripts.
I use `#!/usr/bin/env sh` in my scripts to avoid having to overwrite a systems defualt /bin/sh and whatever issues that can result in. Instead, I have ~/.local/bin in PATH with dash symlinked to ~/.local/bin/sh
More and more often, I am getting the following error:
Malware and Phishing
This site is blocked because it is a known security threat. Please contact your network administrator to gain access.
My assumption this is because I have Xfinity Business Class and it's blocking the site. But why would I be seeing this so often on a site linked from HN?
+1. What's the point of a great shell, if I can't run the millions (!!) of existing scripts without refactoring them?! Zsh does the autocompletion just as well, so I'll stick with that.
You don't need to rewrite any script as long as your scripts have the correct shebang, those scripts works perfectly.
I would strongly not advise to make it the default shell though as this can lead to issues. The way I use it is to have bash as my main shell but my .bashrc starting fish if it's not started explicitly from bash: (it's a trick form arch wiki)
if [[ $(ps --no-header --pid=$PPID --format=cmd) != "fish" ]]
then
exec fish
fi
I've been using fish for a long time with this setup and never encountered an issue.
> I would strongly not advise to make it the default shell though as this can lead to issues.
I've heard this a lot, but I've been using Fish as my login shell for many years, and it's really not a problem
I think maybe some vim plugins call out to your $SHELL or something, but assume that it's bash-like? but I've never run into a serious issue with just using Fish as my login shell
That would be a nightmare for sure. I can't blame you for being cautioned by an experience like that.
I've been running Fish as my login shell for almost 10 years now, on Linux and then additionally for ~4 years for intermittent macOS usage (only at work) without issue.
I don't really like launching Fish from ~/.bash_profile because or similar because I don't like having to type `exit` twice to exit, and `exec`ing into Fish leaves you in one shell but with your $SHELL variable set to another.
But if that works for you, more power to ya, and it's good for Fish users to know that that's an option if they run into issues using Fish as a login shell.
Does your profile call `exec fish -i` rather than just `fish -i`? In that case, you'll only exit once :)
From the `exec` manual:
If exec is specified with command, it shall replace the shell
with command without creating a new process. If arguments are
specified, they shall be arguments to command. Redirection
affects the current shell execution environment.
I can't think of a single reason why you'd need to rewrite your POSIX sh or bash scripts to be able to use Fish. The `#!/bin/sh` shebang is there for a reason.
> Smart tab completion not only for the commands but for the arguments as well, and it apparently does that by parsing man pages.
And it does this every time you spawn a shell. So if you have set your login shell to fish, then every time you launch a shell it loads all the fish plugins like this one, and that slows it down. And you can’t turn it off, or couldn’t the last time I checked around a year ago. Insult to injury? The PR where this was requested was closed by the devs as “wontfix”.
This, and it’s lack of POSIX compatibility, made me switch back to zsh.
I have been using fish for years. I don't have those issues because I just leave the default as bash and run the fish command manually when I log in. Then if I have some incompatibility (pretty rare) I can just type 'exit'.
On NixOS, we generate the completions on behalf of users at install time, so they never have to see a slow startup at all. Fish makes it easy to do! Thanks :D
> So if you have set your login shell to fish, then every time you launch a shell it loads all the fish plugins like this one, and that slows it down
Fish completions and functions are lazy-loaded, so this doesn't happen unless you write your config to force it to happen.
Fish also provides you with functions you can use to check whether a shell instance is a login shell, is interactive, or is just being invoked as (part of a) script. If you do have some heavy-duty stuff you want to run on startup for your login shell or your interactive shells, you can do that selectively and keep Fish startup for other purposes fast.
Shells and scripting languages are different things. I don't care how good of a scripting language Powershell is, it's painful to use as a shell. I don't care that fish can't run sh scripts, I've never used it on a machine that didn't have sh. Can we stop judging oranges for their lack of crunch?
Yeah, I hear a lot of people throw shade at fish and then act equally surprised when I don't run my scripts with it. Much like Bash, Perl, Python or even ZSH by some respects, fish is just another tool in my toolbox. It so happens to be the one I default to though, which for some reason sends people flying off the handle.
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 serious. Some day I'd like to use something like Elvish or Nushell for both, and use the same language as my interactive shell.
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.
You could do that, but it would be pretty inconvenient in general, and more so when using quotes within the script. There would also be no autocomplete.
So I don't think this quite solves the issue you describe, which is that if your history was full of convenient Fish one-liners, you wouldn't be able to reuse them in your scripts, because for scripting you prefer Bash.
But:
1. I have CTRL+R bound to fuzzy reverse history search via fzf in my Fish config. It works great. It's fast, and it's way better than the built-in Bash reverse history search imo, even though it works basically the same way (it should feel very familiar). fzf itself comes with the keybindings, so you don't have to sort them out yourself; you can just source 'em: https://github.com/junegunn/fzf/blob/master/shell/key-bindin...
2. For one-off one liners you see in GitHub repos or something, if you really want tab completion and syntax highlighting and whatever, you can just use `exec` twice:
⋊> ~ echo $HELLO
⋊> ~ exec bash
~ $ export HELLO=hello
~ $ exec fish
Welcome to fish, the friendly interactive shell
⋊> ~ echo $HELLO
hello
3. If you want to import your handy one-liners from your existing `.bash_history`, you could try using babelfish to automatically translate them, then import them into your Fish history: https://github.com/bouk/babelfish
It may not work right for some of them, but it's worked on the scripts I've tried. You might also be able to bind a key that translates whatever command there is on the prompt into Fish. It seems to handle the basics well, including subshells with redirection/process substitution, e.g.:
~ $ cat <(echo hi)
hi
~ $ history | sed -E 's/^[[:space:]]+[[:digit:]]+[[:space:]]+//g' | grep -E '^cat' | tail -n1 | babelfish
cat (echo hi | psub)
~ $ fish
Welcome to fish, the friendly interactive shell
⋊> ~ cat (echo hi | psub)
hi
⋊> ~ exit
~ $
Babelfish is pretty fast. Maybe you could create a Fish keybind that searches through your bash history, only it's translated to Fish via babelfish? Then at least you could keep your existing history in a way :D
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.
> Ideally you do want them to be the same, so that the skill of using one reinforces the skill of using the other,
I've used several dozen shells, script languages, and programming languages - and have needed to do within the context of a single job. What's one more? For an interactive shell I prioritize writeability, and for scripts I prioritize readability and maintainability. These are often at odds - not just in what I write, but in the syntax itself - and by making my shell and script the same, I make middling compromises resulting in a jack of all trades that is a master of none.
I disagree that this is "ideal".
> and you can begin to shape scripts out of your shell history.
It's been my experience that this is quite doable even when the scripting language has different syntax than your shell. Oh, sure, it's not as simple as Copy+Paste - but it's never that simple. Even simple shell scripts inevitably end up needing error checking, sanity checks, error messages, ...
Eh. Tbh I'm find both powershell and unixy shells have their advantages and warts. I'm not sure either is "better". Maybe I'm just not a fan of shells in general.
Actually, in the last few years this gripe has gone away, at least for me. Once they added proper support for `VAR=val cmd && othercmd`, I haven't run across any one-liners that didn't work in fish.
Because for you these are two distinct phases. But how many times you use a for loop for launching the same command multiple times? How many time you pass the output of the command as a parameter to another with $(command)? Or you use variable to save things?
Beside very basic usage, a shell is really a REPL for a scripting language. You can type commands but also you can do most advanced things (and that is what makes shell powerful). For example I maybe have to convert all the video files in a directory, and then upload them to a server, I can easily do that with a for loop in the shell, without creating a script.
And since you use both the shell to type commands and to write effectively scripts as in a REPL, that means that you have to learn another completely different programming language, the fish language (of course I assume that you already know POSIX scripting), and not only that, it's probably the case that only on your computer you have fish but it's not installed on every other system, so when you are using another computer (a server, a computer of a coworker that you are helping, etc) you will make mistakes because you confuse the fish syntax with the one of POSIX shell.
Yes, it's true that bash extends POSIX, and zsh too and it's not even compatible 100% with bash, but the differences are in things that it's rare that you will use in a basic script, and all these shells can understand POSIX syntax. A for loop it's the same in sh, bash and zsh (there is a shorter syntax in zsh, but the base one is the same), while it's completely different in fish.
It is typical HN that everyone is talking about Zsh and how it isn't so bad. And you know what, I used it for a while long time ago, and it is great. I even had config I could transport to another machine when I need.
All that can't be compared with fish out of the box, which is why I am using fish, it will be 10 or so years now. When I say use, I mean that, I just use it, I don't spend time learning it's obscure features, creating scripts etc, no, just use it.
I have alias list that I use to make myself productive and it goes along with me to a new machine. Very slim and simple configuration. That and Vim, but that is another story.
Yes, I could fiddle and twiddle with settings and configure a nicer shell, but Fish on its default settings on any OS just makes things smooth and easy!
> You can configure your shell using a web interface! Just run fish_config
As much as I like the fish shell, I really consider this an anti-feature. A TUI application to configure the shell would make much more sense. The terminal emulator is your platform, not the Web.
Strongly agreed here, it really just works. Sure you can get the same with zsh but the hours of my life I've spent tweaking and tuning zsh I'd happily give back because fish is good enough.
When we built our CLI for Crunchy Bridge it was a couple lines to add tab completion to the CLI when running in Fish (https://blog.crunchydata.com/blog/introducing-the-crunchy-br...), love that when building such tooling giving a better end user experience was so simple.
I've got way too many years of bash under my belt to invest in another shell. I gave oil shell a solid look and decided to not use it. While that may sound wrong, I dont see oil shell having enough features that are different enough to sway people over. I can't think of the saying here, but essentially its not disruptive in the shell space.
Also, it's just shell. By the time I end up with a complicated shell script, i've rewritten it in go, python, etc.
This is just my two cents, if I see more people talking about and using oil shell, I may reconsider.
I've not tried for a while but just getting that to even compile was a nightmare. It seemed to be a fork of the Python 2 code base. They've done the right thing by having a POSIX compatible layer but I completely disagree with their idea of what is wrong with the existing Bourne syntax and needs changing. An interactive shell needs to keep special characters to a minimum and stick to commands as the basic unit on which things are built. Zsh is already able to correct many of the worst elements of the Bourne syntax.
301 comments
[ 0.21 ms ] story [ 250 ms ] threadExtend, embrace, extinguish?...
So thanks, but not thanks. Not to me.
Wouldn't be much more practical to use all of those talent and ideas to help to improve the extant bash shell instead?
See plan9, RedoxOS, TempleOS, Gemini, etc.
None of these are currently in a position to gain dominance, but they all explore a space that couldn't be explored starting with a prior code base.
The EEE analogy is more applicable to GNU Bash anyways: it extended the POSIX sh baseline with a bunch of GNUisms that a lot of "POSIX" sh scripts now unintentionally use.
[1]: https://en.wikipedia.org/wiki/C_shell
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 the new ksh 1988 features that have not been included in the POSIX shell, e.g. condition testing "[[ ... ]]" and arithmetic testing "(( ... ))".
2. All the new features added by ksh 1993, none of which have been included in POSIX, e.g. "for (( ... ))" and the extra parameter expansions that replace the most common invocations of sed or awk.
3. The brace expansion from csh
4. The extended brace expansion forms added by zsh (which generate arithmetic progressions and are usually preferable to "for ((...))")
Attempting to write POSIX-compliant scripts in 2021, i.e. not using these extra ksh/csh/zsh features provided by bash, is a huge mistake in my opinion, because without these features any non-trivial script becomes much longer and much more error-prone.
The Google recommended style for shell scripts (https://google.github.io/styleguide/shellguide.html), which is based on using all bash features, is pretty decent. It is far less work to ensure that bash or ksh/zsh exists on any target system than to maintain any obsolete POSIX-compliant scripts (which are stuck to the 1979 Bourne shell features + only half of what ksh 1988 has added).
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.
I assume that you refer to the "${PARAMETER@OPERATOR}" type of parameter expansion, which is mostly used to either replace invocations of tr for character conversions or to provide quoted strings.
You are right that this kind of parameter expansion is specific to bash and I was wrong when I have said that there are no bash specific parameter expansions. "${PARAMETER@OPERATOR}" is the only exception that was introduced by bash and which has not been taken from the Bourne or Korn shells.
I have forgotten about it, because I do not use it, precisely because it is the parameter expansion variant that is provided only by bash.
Yeah, good luck with that.
It's a garbage pile of code that creates an interpreter with piles upon piles of undefined behavior that random scripts out there in the world rely on.
I don't even think it was a working CI setup.
I'd be super glad to be proven wrong, maybe things have changed in the meantime.
I found that while fish has better syntax than bash for most things, the hassles with incompatibility or unexpected behavior brought me much more trouble than BASH's syntax ever has
https://github.com/edc/bass
Another random tip: python virtualenv generates a activate.fish script that you should use instead of the plain activate script.
It basically runs the script in bash, diffs the environment, and applies the environment changes to your outer fish shell. I use it for some internal tools, and previously used it for nvm though I moved from nvm to fnm now which has fish support.
The only thing I ever used bass for was this edge case where at work the way we login to AWS is using this Okta AWS integration that prints out a list of export commands.
Since fish isn’t compatible with bash export commands, I just run that command result through bass, which automatically converts them to the fish set -x commands.
If I remember right, I think the reason why the bash script my company made didn’t work is that the export commands that were run in bash weren’t propagated to the underlying fish environment. I was using fish to run a script with a separate shell, so it didn’t affect my environment variables.
Or maybe it was because running exec inside a bash script throws you back into fish which then can’t understand the export command.
I could have definitely done my own thing with sed/awk instead, but I suck at those tools and someone else already implemented the functionality in bass.
(Off the top of my head, I think it was something like that, could be misremembering! And by this comment you might be able to tell that I’m far from an expert on how everything works.)Shebangs are actually handled by the operating system kernel! I only know this because certain kinds of shebangs work on Linux, but not on other OSes
Can you also share what are the most significant problems with posix incompatibility for you? Why is it a problem?
Internally we have a boot strap run book developers/operations to bring up either Windows/WSL or MacOS to a consistent shell env.
MacOS has version 3.2.57(1) Ubuntu has version 5.0.17(1)
Apparently Apple cites license concerns as the reason for not upgrading it. Don't know how valid that is.
License on version 3.2.57 is GPLv2 License on version 5.0.17 is GPLv3+
It's simple enough to update if you use homebrew.
`brew install bash`
Add the brew version of bash to the /private/etc/shells and change the shell.
I’ve recent switched from vanilla bash to ZSH. I mainly use oh-my-zsh and Power10k. Once again the defaults without much customization.
https://github.com/sorin-ionescu/prezto
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
https://github.com/zdharma-continuum/zinit
The fact that I can write a simple for loop without needing to look up how to do it by far beats the POSIX compatibility, if I need it I can still write a bash script, but when using the shell I don't need to recall where semicolons or `do`, brackets (and how many) go.
Did the same, but moved on.
Now it is: bash => zsh => fish => nu
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, IMO the reality is that zsh’s “bloat” is pushed into user configuration and the user is tasked with making it work.
As for a replacement for oh-my-zsh itself, I had good experiences with zgen[1] but the fastest I've found is zim-fw[2] which produces acceptable start times for me[3].
[0] https://github.com/romkatv/powerlevel10k/
[1] https://github.com/tarjoilija/zgen
[2] https://github.com/zimfw/zimfw/
[3] https://i.imgur.com/mPPQuyh.png
For example, to me, it is _insane_ that in 2021 async prompts are not a completely solved problem. The shell should provide a mechanism to do so easily, rather than duct-taping thin veneers over syscalls via a scripting language.
I've found that sometimes the opposite can be true (in a good way!). At one workplace, I introduced Fish to some fellow developers who until then mostly saw using the command line as a strange, difficult, and unpleasant part of their jobs.
Once I got them started with Fish, they were happy enough with default interactive behaviors, convenient documentation, and simple scripting syntax that it encouraged them to do a little more scripting, and eventually to customize some of the aesthetic stuff by writing custom prompts!
It was pretty cool to see.
This is such an incredibly odd perspective to me. I use zsh and have not touched my shell config in years. Messing with configurations to get things working to your liking is a one time thing. I don't even use plugins.
On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible. You are forced to give up and use something else. Your reason to choose fish is only a good reason if you already agree with every minute choice the developers made and refuse to let you adjust.
What do you want to do that isn't possible? I also haven't messed with it in months if not more (fish in my case, not zsh) but years ago I messed with the prompt a lot to get it to my liking. (From a previous zsh config.) It was perfectly possible.
Which part of fish makes this impossible? You can tweak the startup, the completions, the key bindings, the prompt, and so on.
I went through a "distro hopping" phase at some point with Linux and ended up settling on a system with very little custom config. It's close to the defaults so I can work very comfortably even in a random server.
Of course this is not ideal. If you have a tool or set of config that you like, then you should use it. I've just found that the human brain can overcome bad UX quite well with a little effort ;)
Omz != Zsh.
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 and scripting shell but I don't have the time or willingness to configure it when fish offers a nice out of the box experience. Not to mention that zsh shouldn't be used as a scripting shell in the first place.
Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?
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 well-suited to interactive use. The Oil shell wiki has a great list of them (and Oil is one such shell itself, of course): https://github.com/oilshell/oil/wiki/Alternative-Shells
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.
I guess there are two reasons
- if the script doesn't need arrays, POSIX sh (dash) scripts will be much faster than bash/zsh scripts
- if you do need arrays, bash is vastly more ubiquitous than any other shell on the planet right now (except POSIX sh). It's installed on almost all Linux distributions by default. I'm not gonna use a ZSH script because I'd have to install ZSH, which seems unnecessary. A good example is tomb, which is a ZSH script for encryption on Linux.
If you're sure that your scripts will always run on macOS, use POSIX sh if you don't need arrays and ZSH if you do need them.
I script in bash (though I'm super interested in oil), and use fish as my interactive shell, it's pinned to screen 0 in my screen session.
I don't write shell scripts a lot, I prefer to write python scripts (that are more maintainable and simple to write). But I write complex commands in the shell a lot, for example I may need to convert a bunch of images from one format to another, just use a for loop with imagemagik directly from the command line, then maybe a regex with sed to rename them, and done. It's not rare that I write commands that are more than 5 lines long.
With all the quirks of POSIX shell scripting languages (well in reality I use zsh that is nicer) they let you hack things together fast, and that makes them powerful.
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 separators look ugly and unwieldy to me. A text editor like vim would do a far better job handling those 5 lines instead of an interactive shell.
The more languages you know the more valuable you are. I prefer to only write golang but sometimes that leads to typescript, Makefiles and bash scripting as well.
such as?
You should keep using bash as your default login and user shell, define your environment variables, like PATH, in your `.bashrc`/`.bash_profile` but use fish as the default shell of your terminal emulator. In that case, fish should pick up the PATH from bash.
https://github.com/search?q=fish+support&type=issues
Unlike what some people may think, it's not just about the tool itself but its ecosystem as well.
I kind of forgot that even use it until I read your comment :)
Really nice shell though, I hope it gets more traction.
I hated Apple, but my opinion changed when I learned how to configure ZSH.
Nushell takes the ideas behind Fish even further by incorporating types other than strings and adding more built-in functionality that’s useful for your average command-line user.
I doubt I’ll go back but both are great! Highly recommend Fish and Nushell!
Just tried it and there's no
I'm not sure I've ever opened my fish config file, but I'm still able to customize it easily
I want to like it. It's goals and purposes seem to be in the right place, but....
Nope.
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
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.
1. You have to go out of your way to fetch the full help pages on a given PowerShell installation (they're not stored locally by default).
2. Even after you fetch the full help, not all of it is actually included in the Get-Help output (IIRC examples), so you often need to use `Get-Help -Online`, which opens a separate application (browser) and that sucks
3. Inside the terminal, there's little to no special formatting or syntax highlighting, unlike what you get with a good `man` pager
4. Get-Help output (unlike `man` output as configured on most distros) is not paged by default.
`man` could be better, and I don't really vibe with `info`, but Get-Help isn't that great imo. The actual content of the help is quite good, and it's nice that it includes examples, but the same is true of most man pages.
Though, I’m keeping a very interested eye on Nu shell. They’re doing a lot of stuff right, and I expect it will become a very useful scripting language in its own right even when not used full-time as a shell.
That's weird. Fish has all of the GNU readline shortcuts OOTB and has for as long as I can remember
I guess it does the PATH hacking based on whether the system is GNU or not so that it can get `realpath`/`readlink -f`-like behavior even on systems that don't natively have that because they include *BSD coreutils.
That might not behave as expected (and is unnecessary) on my macOS systems, either, since I like to keep GNU coreutils (with no `g` prefixes on the executable names) on my PATH there (heresy, I know).
It's also noticeably slower, to the point that there's a bit of jitter as I type.
It's pretty cool, though. If it's any better after I patch the readlink PATH hacking out, maybe I'll configure it for bash on my systems.
https://media.handmade-seattle.com/nushell/
Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
> Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
Hahahaha! Oof.
It's more work, but when I use PowerShell, I try to use pure PowerShell, both for aesthetic reasons (cleanliness, ‘portability’) and just in order to practice and learn more PowerShell APIs along the way.
Now-If-They-Could-Improve the Syntax To-Make-It-Usable.
That said: what do you like about Nu shell specifically?
A whole bunch of things:
1. abandonment of POSIX shell syntax. We can do better. I'm happy with Zsh being POSIX-compatible, and that will always be there.
2. a focus on structured data. Nu basically has hierarchical dataframes built-in, along with lots of facilities for their manipulation. There have been a few other attempts at this but the benefits are obvious. Rather than figuring out how to `awk` your way through whatever text output a command generates, command output in Nu is structured and everything can be handled in orthogonal ways.
3. modern conveniences built-in, like syntax highlighting, and AFAIK they want to include features like "do something when you cd into a directory" that we currently need more tools for (i.e. direnv, which I highly recommend!)
4. serious technology. The people behind it are experts and JT has been showing off (https://youtu.be/3o8b_QcrFHc) the engine that enables trivially parallelizable loops. No more need for `xargs`.
5. I hesitate to mention "made in Rust" as a feature, but using a modern language for core infrastructure does matter.
The thing is, there's currently NOTHING GOOD for "shell scripting". Shell sucks (yes it does), so for anything more than very short things I'd rather write Python. But Python sucks for shell-like things, parallelization, it has slow startup, and you also can't do things like put environment variables into your session or change the working directory, so you often wind up writing shims (eg. Broot's br alias - https://dystroy.org/broot/install-br/).
Yes I've looked at Xonsh but maybe the additional syntax is offputting to me. Like, I wouldn't use it as a shell over Zsh (how's Xonsh's fzf support? I don't know, but I know everything's going to support Zsh), and I dunno if I want to use its syntax extensions over just Python. Though It's always on my list of things to re-explore, and maybe it'll click one day. But it being based in Python makes it feel slow (I wrote my prompt in Zig to get it to be fast...)
This is relevant to mention: I wrote a small Python library (https://github.com/kbd/aush) that's basically a DSL for subprocesses, so it tries to make it more convenient to do shell-like things. I find it preferable to shell or Python alone most of the time. Here's an example of its use in my script that creates a new Python project: https://github.com/kbd/setup/blob/master/HOME/bin/create-pyt...
I haven't figured out a convenient way to implement shell piping well with Python's pipe operator, or pass through interactive output directly (so things that "update" the display, like poetry and npm don't behave the same as they do interactively) so it's still .9 status, but it works really well for what it is, and you can always write "regular Python" along with it.
Anyway, Nu seems to be an attempt to put a "real" programming language REPL in my shell, from people who have serious language experience, so I'm hopeful it'll be great.
I appreciate the clarity of your message... curiously enough all the things that you mention I see them as anti-features of nushell (except the first one)
1. Posix shell is clunky has its limitations but there's nothing really flawed about it. It is nice to have non-posix shells, though; in that I agree with you.
2. I hate hate hate the very concept of dataframes. They seem like a useless over-engineering. Plain tabular data is a perfect, and the columns of a table are always named 1, 2, 3. The whole point of abstraction is that you do not care about the meaning of the columns of your table, and the programs (like the lovely awk) that deal with these columns do not care either. There's nothing more "orthogonal" than that: filters that do not understand the data but can filter it anyway.
3. syntax highlighting is a very personal issue; in my case I prefer my terminal not to look like a christmas tree.
4. xargs is one of my favorite tools (alongside gnu make and gnu parallel) and there's nothing "unserious" about it. The happiest moments in my programming life are when I get to use these tools. Not using xargs sounds like a nightmare!
5. Rust is definitely an anti-feature to me: it's like a language that was built by picking the worst features of many already ugly languages. I would not really care in what language the shell is written, but I'd rather have it written in saner, "unsafe" languages.
I think shellcheck is the best argument against this. POSIX shell is just stuffed to the brim with weird gotchas, places where the obvious way to write something causes subtle bugs down the line.
It's the only programming language I use that feels adversarial, where you have to be paranoid to properly solve simple tasks. (Admittedly some of that is because of the reliance on system programs rather than the shell language itself.)
This may be just that you are not very used to the language. I have the same dreadful feeling (that the language fights against me), even when using languages that I'm reasonably proficient with.
For example, in C++, a simple expression like "y = f(x);" already gives me the chills... Is the () operator overloaded? and the assignement operator? If the object x has size equal to 10GB, and y is supposed to have the same size, how much memory does this operation require? 10GB? 20GB? 30GB? 40GB? each of these completely different answers is perfectly reasonable, depending on extremely delicate details of the implementation.
Garbage-collected languages are even worse, I never know whether they will start a memory reclaiming spree that will halt my program for a few seconds.
Even in python, I have this sort of jump scares a few times per month.
The point of fish is that there is no configuration required.
You don't have to learn to configure it, you don't have to be part of "the community" to learn which plugins to use, you'll be able to sit in front of any fish prompt and have it work as expected without having to move dotfiles around.
I use Fish, however I also use Vim and do the plugin hunt there. I enjoy it, but I’m glad to not be doing it for both my environments.
I think it would be more accurate to say that the point of fish is that there is no configuration allowed. If you don't like the out of the box configuration, I would say configuration is still required, but it's unfortunately not available. If you happen to like every single decision the developers made, then I admit having no configuration does mean you end up with a simpler, faster, more maintainable shell.
Then either decide to like it -- humans are adaptable, this is possible -- or don't use the thing. Both outcomes are acceptable. A hammer doesn't need to have a configurable grip and head and claw in order to be a good tool.
A: Linux is amazing, I can configure everything the exact way I want.
B: Linux sucks, I need to mess around with configurations for hours before I get something usable.
A lot of us just want something that works out of the box with amazing defaults. Others want something that can be tuned to their exact preferences. However, configurability comes with it's own costs too.
You can configure scripting to run at various times, and there are even plugin frameworks for Fish. It just doesn't have toggles for things like language features in the way that ZSH does.
In recent years the existence of frameworks like oh-my-zsh has contributed further to this situation because it has separated the detailed configuration from the base zsh project. It's a pity omz doesn't enable more really. Many things it does are not really useful unless you take the time to actually learn them. A lot of plugins just define aliases but if you don't know what they are, they just sit there unused.
Edit: also things like `kill`. `kill [tab]` gives you a fuzzy-find list of all your processes so it's way faster to use than ps | grep.
Unknown user on discord
Most people do not have a dotfiles repo.
Of course you can get even more involved and manage your dotfiles with ansible or something but the advantage of a tool like fish is that it's almost perfectly usable out of the box. More config files will always increase the chance for things breaking.
https://gist.github.com/abhigenie92/a907cdf8a474aa6b569ebe89...
The default setup is pretty much perfect for what I want. My only additions are fzf for history search, a bunch of aliases and Starship for informative status lines.
This is the reason, why I try to prevent using bash/zsh exclusive features in my daily use scripts.
Think about that for a while.
Malware and Phishing
This site is blocked because it is a known security threat. Please contact your network administrator to gain access.
My assumption this is because I have Xfinity Business Class and it's blocking the site. But why would I be seeing this so often on a site linked from HN?
You might want to reach out to Xfinity support, or bypass their filter using a VPN or proxy.
I would strongly not advise to make it the default shell though as this can lead to issues. The way I use it is to have bash as my main shell but my .bashrc starting fish if it's not started explicitly from bash: (it's a trick form arch wiki)
if [[ $(ps --no-header --pid=$PPID --format=cmd) != "fish" ]] then exec fish fi
I've been using fish for a long time with this setup and never encountered an issue.
I've heard this a lot, but I've been using Fish as my login shell for many years, and it's really not a problem
I think maybe some vim plugins call out to your $SHELL or something, but assume that it's bash-like? but I've never run into a serious issue with just using Fish as my login shell
I've been running Fish as my login shell for almost 10 years now, on Linux and then additionally for ~4 years for intermittent macOS usage (only at work) without issue.
I don't really like launching Fish from ~/.bash_profile because or similar because I don't like having to type `exit` twice to exit, and `exec`ing into Fish leaves you in one shell but with your $SHELL variable set to another.
But if that works for you, more power to ya, and it's good for Fish users to know that that's an option if they run into issues using Fish as a login shell.
From the `exec` manual:
https://man7.org/linux/man-pages/man1/exec.1p.htmlWhat? No it doesn't. Shebang exists for a reason, and you should ALWAYS use it anyway, fish or not.
And it does this every time you spawn a shell. So if you have set your login shell to fish, then every time you launch a shell it loads all the fish plugins like this one, and that slows it down. And you can’t turn it off, or couldn’t the last time I checked around a year ago. Insult to injury? The PR where this was requested was closed by the devs as “wontfix”.
This, and it’s lack of POSIX compatibility, made me switch back to zsh.
It does not. The completion generation is on first start and whenever you run `fish_update_completions`.
(note that the importance of man parsing is often quite overstated, it only gets you so far, all the advanced completion stuff is hand-written)
Source: I'm a fish dev.
Fish completions and functions are lazy-loaded, so this doesn't happen unless you write your config to force it to happen.
Fish also provides you with functions you can use to check whether a shell instance is a login shell, is interactive, or is just being invoked as (part of a) script. If you do have some heavy-duty stuff you want to run on startup for your login shell or your interactive shells, you can do that selectively and keep Fish startup for other purposes fast.
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 serious. Some day I'd like to use something like Elvish or Nushell for both, and use the same language as my interactive shell.
But:
1. I have CTRL+R bound to fuzzy reverse history search via fzf in my Fish config. It works great. It's fast, and it's way better than the built-in Bash reverse history search imo, even though it works basically the same way (it should feel very familiar). fzf itself comes with the keybindings, so you don't have to sort them out yourself; you can just source 'em: https://github.com/junegunn/fzf/blob/master/shell/key-bindin...
2. For one-off one liners you see in GitHub repos or something, if you really want tab completion and syntax highlighting and whatever, you can just use `exec` twice:
3. If you want to import your handy one-liners from your existing `.bash_history`, you could try using babelfish to automatically translate them, then import them into your Fish history: https://github.com/bouk/babelfishIt may not work right for some of them, but it's worked on the scripts I've tried. You might also be able to bind a key that translates whatever command there is on the prompt into Fish. It seems to handle the basics well, including subshells with redirection/process substitution, e.g.:
Babelfish is pretty fast. Maybe you could create a Fish keybind that searches through your bash history, only it's translated to Fish via babelfish? Then at least you could keep your existing history in a way :DI've used several dozen shells, script languages, and programming languages - and have needed to do within the context of a single job. What's one more? For an interactive shell I prioritize writeability, and for scripts I prioritize readability and maintainability. These are often at odds - not just in what I write, but in the syntax itself - and by making my shell and script the same, I make middling compromises resulting in a jack of all trades that is a master of none.
I disagree that this is "ideal".
> and you can begin to shape scripts out of your shell history.
It's been my experience that this is quite doable even when the scripting language has different syntax than your shell. Oh, sure, it's not as simple as Copy+Paste - but it's never that simple. Even simple shell scripts inevitably end up needing error checking, sanity checks, error messages, ...
Beside very basic usage, a shell is really a REPL for a scripting language. You can type commands but also you can do most advanced things (and that is what makes shell powerful). For example I maybe have to convert all the video files in a directory, and then upload them to a server, I can easily do that with a for loop in the shell, without creating a script.
And since you use both the shell to type commands and to write effectively scripts as in a REPL, that means that you have to learn another completely different programming language, the fish language (of course I assume that you already know POSIX scripting), and not only that, it's probably the case that only on your computer you have fish but it's not installed on every other system, so when you are using another computer (a server, a computer of a coworker that you are helping, etc) you will make mistakes because you confuse the fish syntax with the one of POSIX shell.
Yes, it's true that bash extends POSIX, and zsh too and it's not even compatible 100% with bash, but the differences are in things that it's rare that you will use in a basic script, and all these shells can understand POSIX syntax. A for loop it's the same in sh, bash and zsh (there is a shorter syntax in zsh, but the base one is the same), while it's completely different in fish.
Fish shell - https://news.ycombinator.com/item?id=27180420 - May 2021 (118 comments)
Fish Shell 3.2 - https://news.ycombinator.com/item?id=26302678 - March 2021 (128 comments)
Fish is not operational on a VT220 terminal (2015) - https://news.ycombinator.com/item?id=25526237 - Dec 2020 (113 comments)
New Features in the Fish Shell - https://news.ycombinator.com/item?id=24631138 - Sept 2020 (138 comments)
Dolphins learn from their peers to use empty shells to catch fish - https://news.ycombinator.com/item?id=23660910 - June 2020 (8 comments) (<-- just kidding)
Fish: A command line shell for the 90s - https://news.ycombinator.com/item?id=21361696 - Oct 2019 (83 comments)
Fish shell 3.0 - https://news.ycombinator.com/item?id=18776765 - Dec 2018 (220 comments)
Fish: A user-friendly command line shell for macOS, Linux, etc - https://news.ycombinator.com/item?id=15910897 - Dec 2017 (204 comments)
Fish (Shell) for a Week - https://news.ycombinator.com/item?id=14422672 - May 2017 (2 comments)
The fish shell is awesome - https://news.ycombinator.com/item?id=14179081 - April 2017 (7 comments)
Fish Shell Design Principles - https://news.ycombinator.com/item?id=11102941 - Feb 2016 (71 comments)
Fish shell 2.2 - https://news.ycombinator.com/item?id=9873090 - July 2015 (70 comments)
Fish shell - https://news.ycombinator.com/item?id=9566441 - May 2015 (182 comments)
FISH Shell: A dynamic shell - https://news.ycombinator.com/item?id=8783150 - Dec 2014 (3 comments)
Fish shell 2.1 - https://news.ycombinator.com/item?id=6626635 - Oct 2013 (151 comments)
fish shell - https://news.ycombinator.com/item?id=6224524 - Aug 2013 (75 comments)
Fish shell 2.0 - https://news.ycombinator.com/item?id=5723235 - May 2013 (175 comments)
Fish 2.0 shell beta - https://news.ycombinator.com/item?id=5567639 - April 2013 (56 comments)
Fish: Finally, a command line shell for the 90s - https://news.ycombin...
All that can't be compared with fish out of the box, which is why I am using fish, it will be 10 or so years now. When I say use, I mean that, I just use it, I don't spend time learning it's obscure features, creating scripts etc, no, just use it.
I have alias list that I use to make myself productive and it goes along with me to a new machine. Very slim and simple configuration. That and Vim, but that is another story.
i have a collection of them in my .zshrc that i would love to use.
there's also abbreviations like
which expand as you type. ll won't end up in your history because it's expanded before that.The killer feature over aliases is that a) you can edit them and b) you can define them instantaneously.
Did you type `git diff --cached` one time to many? Up arrow -> Ctrl+a -> "abbr gdc " <enter>
Bam. `gdc<space|enter>` now expands to that. It's there forever. And that's how you end up with 100+ abbreviations.
Yes, I could fiddle and twiddle with settings and configure a nicer shell, but Fish on its default settings on any OS just makes things smooth and easy!
As much as I like the fish shell, I really consider this an anti-feature. A TUI application to configure the shell would make much more sense. The terminal emulator is your platform, not the Web.
But you're in luck; looks like the next version will have everything also configurable via text: https://github.com/fish-shell/fish-shell/issues/3625
When we built our CLI for Crunchy Bridge it was a couple lines to add tab completion to the CLI when running in Fish (https://blog.crunchydata.com/blog/introducing-the-crunchy-br...), love that when building such tooling giving a better end user experience was so simple.
Also, it's just shell. By the time I end up with a complicated shell script, i've rewritten it in go, python, etc.
This is just my two cents, if I see more people talking about and using oil shell, I may reconsider.