oursh VS plugin-foreign-env

There is also https://github.com/nixpulvis/oursh which wants to be POSIX compatible with its own extensions. Actually I would prefer if a new shell focuses on bash compatibility.

If features are integrated, then I would probably want to have something about error handling because it is difficult to get right in bash even with shellcheck¹ and gets just worse when things run in parallel.

¹ https://www.shellcheck.net/

A lot of this has to do with the integration between the Terminal and the Shell. A project that came up recently that seems to take on a few of the issues is https://blog.warp.dev/how-warp-works. I've been meaning to write up a proper critique of this project at some point, but I keep getting side-tracked.

I also want a replacement for `fish`, however it's a pretty tall order to implement what I have in mind, and I got a bit stuck trying to find the right abstractions for background job management in Rust (there's a lot going on). But I genuinely believe a multi-language shell with POSIX support will finally allow us to move forward in the terminal environment. UI/UX issues like ctrl-c, window management, and everything else can be implemented as derivations from POSIX, or additions.

While somewhat tangential to the main thread of this post, I'll still leave my (incomplete) shell here for anyone who's interested. https://github.com/nixpulvis/oursh. The README has a decent description of features I want off the bat, and there's a bunch of design level issues in the tracker.

I'll never accept the death of the Terminal environment.

I am not using Guix's Fish because right I just installed it and was hoping to kinda get my packages up to snuff for what I keep on my desktop. Though I was about to install foreign-env via omf and that seems to work! I am super new to Guix so I still gotta read up on Guix Home. I literally have only installed like 6 packages right now haha.

The official installer leverages an initialization script, to be sourced at shell init time, which is written in POSIX shell. Fish can't just source it because it's not compatible with POSIX shell.

> I then searched the Internet and found a very "creative" workaround for Arch users that didn't work either.

Arch users shouldn't need anything special here.

You can use fenv¹ to source it, you can translate it to bash using babelfish, or you can exec into fish after running bash to log in (make sure to set $SHELL after if you choose that option). Just make sure you do it as early as possible if you want to use things installed by Nix in your other Fish config snippets.

I think Home Manager will also take care of this for you. (The other module systems, Nix-Darwin and NixOS, both do.)

If you wanna do it like NixOS does, you can install Fish via Nix and then create your own preinit environment script in /etc/fish. This has the advantage of setting up your Nix environment variables before any other config is sourced. You can take a look at it here, which also explains some of the Fish initialization process: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/p...

and here's where the hooks go in the Fish package, where the comments describe the Fish initialization process in detail as well as why things are done this way on NixOS: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/p...

—

1: https://github.com/oh-my-fish/plugin-foreign-env

2: https://github.com/bouk/babelfish

That's just not true, most stuff already has a fish equivalent, and for the minority which doesn't there are plugins like foreign-env

I'm also interested in the correct way of doing this. Right now, I cheat by using the fenv plugin to source a bash ~/.profile file: