junegunn / fzf

:cherry_blossom: A command-line fuzzy finder
https://junegunn.github.io/fzf/
MIT License
62.32k stars 2.35k forks source link

Fix unreliable GOOS detection #3763

Closed cyqsimon closed 2 months ago

cyqsimon commented 2 months ago

I was alerted to a build failure of the COPR build I maintain yesterday, the nature of which is pretty curious. Here are the relevant lines in the build log:

+ make FZF_VERSION=0.51.0 FZF_REVISION=260a65b all install
fatal: not a git repository (or any of the parent directories): .git
GOARCH=arm64 go build -a -ldflags "-s -w -X main.version=0.51.0 -X main.revision=260a65b" -tags "" -trimpath -o target/fzf-(Red_arm8
bash: -c: line 1: syntax error near unexpected token `('
bash: -c: line 1: `GOARCH=arm64 go build -a -ldflags "-s -w -X main.version=0.51.0 -X main.revision=260a65b" -tags "" -trimpath -o target/fzf-(Red_arm8'
make: *** [Makefile:161: target/fzf-(Red_arm8] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.xvfXRu (%build)

fatal: not a git repository is not a problem because I'm using the tarball as source (with the commit hash obtained using GitHub API). But it's weird that it thinks the target binary should be target/fzf-(Red_arm8. And because it's not shell-escaped, Bash tries to handle ( and errors.

So I went digging for the reason and found that it's because the current Go binaries shipped by RHEL9 have this version string: go version go1.21.9 (Red Hat 1.21.9-2.el9_4) linux/arm64. This made GOOS=(Red which led to the failure.

Considering that this is intended to be a human-readable string with no rigid format, I think it's best to make it not depend on explicit word positions and rely on a search instead.

junegunn commented 2 months ago

Thanks!