so does this mean a native Windows build now?

Absolutely not. Fish may be written in more of a cross-platform language/ecosystem now but as a unix shell, we make heavy use of unixisms that have no windows equivalent throughout its architecture, design, and implementation.

Is it theoretically, someday possible? Sure. Does rust bring us closer? Maybe a tiny bit, but honestly not much (it has a more elegant per-platform targeting/conditional compilation model but it’s nothing that wasn’t possible in C/C++, and we don’t use the “native” oob cross-platform std lib stuff like launching procs).

WSL is a priority target though.

Bash has been ported to windows probably more than once. There are a few clunky corners but it works well enough.

Not gonna say it’s easy but may be less difficult than it appears to some.

Looks like rust is reasonably well working with cygwin/msys2 based on some github issues, https://github.com/rust-lang/rust/issues/79854 . Given that, I'd expect that this rust rewrite should work under them at least. Though it's obviously not a fully native build since you've got a bunch of compatibility layers involved to bring in those mentioned unixisms.

If you’re after a UNIX shell that runs on Windows without WSL / mingw then there are a few options such as Murex and Elvish.

However personally I’d still recommend WSL if just for the coreutils userland.

Disclaimer: I’m the author of Murex shell

clever name choice, unfortunately, it makes search for it almost imposible, because "murex shell" finds only pages about marine life

would you share a link please?

Search for “murex Unix shell”.

Top hit for me is https://pkg.go.dev/github.com/lmorg/murex

Use Nushell instead. It's also written in Rust: https://www.nushell.sh/

A Windows build is explicitly not in the plans, at least today, from what I've seen.

Yeah even if it built, a windows shell needs to do different things. I’ve had some success running it in msys2 though: https://evil.link/2022/03/31/using-fish-shell-on-windows/

Ironically the RIIR project makes this more difficult; we lost support for Cygwin altogether and I think the msys2 stuff would need to be re-explored if it even remains possible.

Would love for there to be an in-depth retrospective on what worked/did not for the porting once they get closer to releasing the first build.

The team is all agreed on the importance of such a write up at some point — but it’s not clear we’ve experienced all the fun stuff as of yet.

There are still many cmake files in the current source code. What are they for? It should be known that rust projects usually do not use cmake.

It says in the post:

> at this stage I think it looks like CMake will be hanging around, much simplified, to handle some of the configure/install targets, while cargo is used for the actual build.

Cargo is an ineffective build system if you need anything that isn't just Rust.

I'm a huge fan of Rust, so although I wouldn't advocate abyone do a total RIIR for most projects, this is very cool to see!

CLI tools are such an obvious use case though, I'd at least consider RIIR if it's purely CLI

Love fish, it's my default shell on my machine where I have a UI, Linux or OSX.

I do wish there was better bash compatibility though, it keeps me from using fish on remote hosts, and some of my work tools are not fish compatible. I usually just switch to bash for a bit, but then I don't have my normal completion, history, git branch identification etc that comes out of the box with fish.

I'm a huge fan of sane defaults. Fish strikes a great balance here where I feel zsh requires a larger minimum amount of effort to be comfortable.

Bash compatibility and sane defaults are contradictory goals.

I use fish, have been for 6 years now? I always default to bash for work scripts and nowadays use justfiles to bring them together. I don't like using fish for scripting, that's what bash is for.