One annoyance of this solution: You have to rerun fish --install on upgrade. I experimented with having it check the mtime of share/config.fish and printing a note if it was older than the fish binary. This generally works, but will trigger too often (e.g. if you move the fish binary after installing).

It might be possible to write a file with the version that was installed and check that on startup instead.

I believe it would be possible to allow this as an option, and to add a static build to fishshell.com so people can just download a fish, without compilation.

Would be prudent to double-check performance of the statically linked version. Four-ish years ago, statically linking with musl could have tanked your performance due to musl's malloc being much slower than glibc one or jemalloc. This issue prevented rust-analyzer from going the fully statically linked way. But I remeber that musl wanted to rewrite the allocator, and, presumably, they had done that since.

Would be prudent to double-check performance of the statically linked version

Pure "--no-config" startup is faster, our other benchmarks are 10-70% slower (memory usage is ~25% less). Of course those are specifically written to mostly measure time spent in fish. Realistically, this is an entirely usable build and it's hard to notice a difference when just running it. Performance in shells is weird, very often most of the time is spent waiting for external commands.

It's "possible" to link glibc statically, but that will crash when you attempt to do echo ~foo (in libnss_something, via getpwnam_r). (this is why we used to forbid static linking in cmake)

The alternative is to offer a self-installable build dynamically linked against glibc, but that obviously requires a compatible (i.e. same version or newer) glibc to what it was built against. This would still be better than the appimage, because that needs libfuse2 and glibc on the host. These are also simple enough to build that we could do both.

This talk is of course secondary to whether having fish self-installable is useful - it would enable cargo install to do something usable, and it could then also be used to distribute cross-distro single-file binaries, whether they are statically or dynamically linked.

The alternative is to offer a self-installable build dynamically linked against glibc, but that obviously requires a compatible (i.e. same version or newer) glibc to what it was built against. This would still be better than the appimage, because that needs libfuse2 and glibc on the host. These are also simple enough to build that we could do both.

Binaries built with newer glibc isn't necessarily incompatible with older glibc. glibc uses symbol versioning to indicate compatibility. I pulled your branch and ran cargo build --release with glibc 2.37, which was released in 2023. readelf -V target/release/fish shows binary requires GLIBC_2.34, which was released in 2021. I don't know how many years of backwards compatibility is most appropriate, but I think building from Debian oldstable or the Ubuntu equivalent should suffice for most people.

So if I had a fleet of 100 servers on varying versions of Ubuntu LTS I could build it on the oldest server and it should be able to be copied to any of the same version server or higher and it would simply run?

I could build it on the oldest server and it should be able to be copied to any of the same version server or higher and it would simply run

If you build dynamically against glibc, yes. If you build statically against musl you can build it anywhere (probably even cross-compile it from macos), at the cost of some performance.

This will give you a per-user fish that needs to install its datafiles by running fish --install, after that fish will be fully capable.

Alright, after a rebase this now crashes on startup - do cargo install --path ., run ~/.cargo/bin/fish, and you'll get a segfault.

Backtrace is:

#0  0x0000555555801744 in fish::fork_exec::blocked_signals_for_job ()
#1  0x00005555557ef2ee in fish::fork_exec::spawn::PosixSpawner::new ()
#2  0x00005555557ea0fc in fish::exec::exec_process_in_job ()
#3  0x00005555557e4bdf in fish::exec::exec_job ()
#4  0x00005555556804ea in fish::parse_execution::ParseExecutionContext::run_1_job ()
#5  0x000055555567f378 in fish::parse_execution::ParseExecutionContext::run_job_conjunction ()
#6  0x000055555567f20a in fish::parse_execution::ParseExecutionContext::run_job_list ()
#7  0x00005555556776a4 in fish::parse_execution::ParseExecutionContext::eval_node ()
#8  0x000055555576fd4c in fish::parser::Parser::eval_node ()
#9  0x000055555576d7fe in fish::parser::Parser::eval_with ()
#10 0x00005555557f6ba9 in fish::exec::exec_subshell_internal ()
#11 0x000055555572d2f3 in fish::expand::expand_cmdsubst ()

debug build might help. This is still pre-fork so that should rule out a class of problems

debug build might help.

Debug build gives an empty backtrace (only ??, no symbols).

Edit: Okay, I'm reasonably sure it's some dependency locking issue. If I run cargo build and run the resulting fish, it runs. But if I run cargo install, the resulting fish crashes and every cargo build after that also crashes until I cargo clean.

Okay I'm reasonably sure cargo install pulled in a newer libc. Pinning it to 0.2.151 (the last version compatible with rust < 1.71) seems to work.

The thing that bites people when using make install into their homedir for projects is that it does not delete files that are no longer installed. (This is why I worked on the development build packages - the only way to reliably manage your filesystem is with a package manager that uninstalls old files. make uninstall is not supported in CMake and in autotools it required a lot of care on the part of developers, which we did not always take.) cargo install will manage the binaries ok, but the fish --install step should possibly install to a versioned directory or similar.

fish --install step should possibly install to a versioned directory or similar.

It currently installs into ~/.local/share/fish/install, so there's the binaries in the cargo binary dir and exactly one directory.

That means uninstallation is cargo uninstall fish; rm -rf ~/.local/share/fish/install, which I feel is simple enough. (or if you want to entirely stop using fish you can just rm -rf ~/.local/share/fish)

A versioned directory could lead to multiple of these being left behind instead of simply overwritten on upgrade.

(plus the biggest issue left here is that installing via git like cargo install --git https://github.com/faho/fish-shell --branch fish-installer will not give you a version because cargo won't pull the tags, so you only get the commit hash)

A versioned directory could lead to multiple of these being left behind instead of simply overwritten on upgrade.

That's fine, but in that case the destination directory should be removed before the extraction starts - it doesn't look like this happens at present. Otherwise, files that are present in one version but not the next will be left behind.

That's fine, but in that case the destination directory should be removed before the extraction starts

Good point, done.

Alright, those last two commits are a bit weird.

The immediate issue is that cargo install --git https://github.com/faho/fish-shell/ --branch fish-installer-test (note that's "fish-installer-test", which I left broken on purpose - this PR is "fish-installer") won't clone the tags. So if you do that right now, you'll get something in $FISH_VERSION (and fish --version) like

fish, version f3fc743fc

which will break a lot of uses of $FISH_VERSION - there is no version there, only the commit sha.

So this detects that case and turns it into

fish, version 3.7.95-g5b00071a7

instead, by using the crate version (in Cargo.toml).

I'm unsure if that is also needed for packages on crates.io.

I changed the crate version (which was still at 0.1.0!) for testing. The version I picked is arbitrary and preliminary, and I am fine with removing it again. Tho I suppose it's not harmful to keep it in?

I would like to try to get some more people to test this - and therefore the next fish version.

We still have more regressions remaining than I would like, especially in corners we don't visit as often and this is really easy to get going as a separate version of fish without breaking your main install.

It would also show if people like this way of installing it, and if anyone has an idea for getting the install/upgrade experience working.

Not sure how much work it would be but getting some form of CI running would be good.

We could publish the crates as pre-release versions. I think it makes sense to do that with a tagged tarball as well?

For the version TODO as a reference, leftwm does this:

    println!(
        "\x1b[0;94m::\x1b[0m LeftWM version: {}",
        env!("CARGO_PKG_VERSION")
    );
    println!(
        "\x1b[0;94m::\x1b[0m LeftWM git hash: {}",
        option_env!("GIT_HASH").unwrap_or(git_version::git_version!(fallback = "unknown"))

Looking so much forward when this PR gets merged 😍

Alright, no use in waiting any longer on this, I'm pressing the big blue button (possibly green for y'all, I'm reasonably sure I have deuteranopia mode turned on).

did you manage to fix HOME=$(mktemp -d) fish and man pages?

I did add the man pages, there's no way to fix HOME=$(mktemp -d) with this.

That's what --no-config is for.

(without resorting to auto-installing, which I am uncomfortable with)

I think a fixed location is the wrong approach

I await your PR. The big problem is that ../share is a terrible directory to use.

Frankly I think our effort would be better invested loading the functions straight from the binary without unpacking, as well as incorporating the help text (that latter one also in non-installable builds).

The big problem is that ../share is a terrible directory to use.

Haven't tried it yet but I think everything would go into ~/.cache/fish, not sure where ../share comes into play.

Anyway, with the current approach, our stance should be that users should not rely on the default location of the support files, because we might change that in future. Probably this is more or less obvious.

Frankly I think our effort would be better invested loading the functions straight from the binary without unpacking, as well as incorporating the help text (that latter one also in non-installable builds).

yes that would be better (with the same interface). Having the raw files available in share/functions is nice but probably not a hard requirement. One can always look at the source

Haven't tried it yet but I think everything would go into ~/.cache/fish, not sure where ../share comes into play.

Whether it goes into ~/.cache/fish or ~/.local/share/fish isn't really important and doesn't solve your question of installing concurrent versions - it's still a fixed location.

You could of course make versioned directories (in either path), but that means you need to figure out how to clean old directories or you're gonna leave them around.

If instead the functions, completions and documentation are read from the binary, you'd only have fish_config and themes there, and those are just much less important to keep up to date.

(the trickiest part is the man pages, which we would have to write out to man for formatting)

@faho - I just tried downloading the last staticbuild artifact for linux aarch64 - however the artifact has already expired - and since the build is only triggered manually there is no newer run. Could you maybe trigger a new one? And any chance the artifact lifetime could be increased a bit for that workflow?

@lukasbindreiter The 4.0b1 release contains copied artifacts at the bottom.

I've now triggered a new run for Integration_4.0.0.

And any chance the artifact lifetime could be increased a bit for that workflow?

We don't want to keep around arbitrary checkpoints for long. We're probably gonna keep the releases.

You can also always build it yourself with cargo build --release --git https://github.com/fish-shell/fish-shell.git --target aarch64-unknown-linux-musl (this requires a musl C toolchain, I've had some success with cargo-zigbuild for targets that zig supports - zig can be installed via pip, so pip install ziglang and then use cargo zigbuild instead of cargo build). If you don't need it static, cargo install just works.

@faho Thank you very much, this resolved my issue! 🙏

Makes sense that you don't want to keep them around for too long - I wasn't aware they were part of the release and didn't check there unfortunately - thanks for the pointer.