Skip to content

[Fix] grammar HTTPS cloning, install.sh broken pipe on fzf/ripgrep, Windows line endings - #3

Merged
halicea merged 4 commits into
mainfrom
2-bug-report-wrong-fzf-release-tag
Jun 21, 2026
Merged

[Fix] grammar HTTPS cloning, install.sh broken pipe on fzf/ripgrep, Windows line endings#3
halicea merged 4 commits into
mainfrom
2-bug-report-wrong-fzf-release-tag

Conversation

@vasilaking

Copy link
Copy Markdown
Member

Summary

Three independent bugs that together prevent a clean install on Linux
(especially from Windows/WSL), fixed and tested end-to-end.


Bug 1 — tsi clones grammars over SSH, failing for most users

File: ts/ts_lang_install.c

Grammar installation used git@github.com: SSH URLs, which require a
GitHub SSH key to be configured. This fails silently for any user who
hasn't set one up (the majority of users, and all fresh environments).

Public repos like tree-sitter grammars don't need SSH, HTTPS works
without any credentials.

Fix: Replaced git@github.com: with https://github.com/ in both
clone URL templates.

Tested: Ran tsi python with the newly built binary and confirmed
the clone line reads https:// with no authentication required:
image


Bug 2 — install.sh fails to install fzf and ripgrep

File: install.sh

The latest_tag() function piped curl directly into grep -m1:

$DL_STDOUT "https://api.github.com/repos/$1/releases/latest" \
    | grep -m1 '"tag_name"' \
    | sed -E '...'

grep -m1 exits after the first match, closing its end of the pipe
while curl is still downloading. Curl then fails with exit code 23
("Failure writing output to destination"). Because the script runs
under set -euo pipefail, this kills the entire function, and
fzf/ripgrep never install.

Fix: Capture the full response into a variable first, then grep
through it. Curl completes before grep ever runs, so no broken pipe:

latest_tag() {
    local json
    json=$($DL_STDOUT "https://api.github.com/repos/$1/releases/latest") || return 1
    printf '%s\n' "$json" \
        | grep -m1 '"tag_name"' \
        | sed -E 's/.*"tag_name"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/'
}

Tested: Confirmed fzf and ripgrep download and install successfully:
image


Bug 3 — Windows line endings break the build and install script

File: .gitattributes (added)

The repo had no .gitattributes, so Windows users cloning it received
\r\n line endings across all files. This caused:

  • install.sh/usr/bin/env: 'bash\r': No such file or directory
  • compile_flags.txt → GCC received flags with trailing \r, producing
    errors like '; did you mean '-Wall'?
  • All .c, .h, and makefile files were similarly affected

Fix: Added .gitattributes enforcing LF for all files:
* text=auto eol=lf

Tested: Verified clean build with make after line ending conversion
on a Windows-cloned copy of the repo:
image
...
image
successful wihtout errors

- Created a `.gitattributes` file to ensure consistent line endings
  across different operating systems, helping prevent issues with line
  ending discrepancies by automatically setting end-of-line (eol) to LF
  for text files
- It improves collaboration by ensuring that all contributors work with
  the same text file formats
- Enhanced the error handling in `latest_tag()` by capturing the result
  of the API call into a variable for more reliable execution
- Improved code readability and maintainability by separating logic into
  distinct steps, helping prevent errors during the tag fetching
  process, ensuring smoother execution of install scripts
- Switched from SSH URLs to HTTPS URLs for cloning the tree-sitter
  grammars, improving the accessibility and avoiding issues for users
  without SSH configuration
- Changing the URLs to HTTPS ensures users can clone repositories
  regardless of their SSH settings
@vasilaking vasilaking linked an issue Jun 21, 2026 that may be closed by this pull request
@vasilaking
vasilaking requested a review from halicea June 21, 2026 11:50
@vasilaking vasilaking self-assigned this Jun 21, 2026
@vasilaking vasilaking added the bug Something isn't working label Jun 21, 2026
Rather than only swapping SSH for HTTPS, attempt both protocols for
each org (grammars first, then upstream tree-sitter), so a clone
succeeds whether the user has HTTPS access, an SSH key, or one is
blocked by a firewall. Whichever works first wins.

@halicea halicea left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll just post one more change here for a https->ssh fallback.

Comment thread ts/ts_lang_install.c Outdated
Comment thread .gitattributes
@halicea
halicea merged commit 8da4a4e into main Jun 21, 2026
1 check passed
@halicea
halicea deleted the 2-bug-report-wrong-fzf-release-tag branch June 21, 2026 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug report] Wrong fzf release tag

2 participants