[BUG] No .gitattributes: Windows clones get CRLF shebangs and the documented Linux/Docker build fails with "/usr/bin/env: 'bash\r': No such file or directory"
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- docker, git, shell
- Domain
- build-system, devops
Research direction
Start by reviewing linux/pre-build.sh, docker/Dockerfile, docs/COMPILATION.MD, and docker/README.md, then check whether the promised PR has appeared. Verify the affected scripts' line endings with a Windows-style checkout and confirm the documented Linux or local-source Docker build no longer fails before compilation.
Written by the indexing model from the issue text.
Description
CCExtractor version: master (2364994a)
Necessary information
- Is this a regression (i.e. did it work before)? NO — the repo has never had a
.gitattributes. - What platform did you use? Windows (clone side). The failure shows up on any Linux build made from that clone.
- What were the used arguments? n/a — this breaks before CCExtractor is built.
Video links
Not applicable; no media involved.
Additional information
Summary
The repo has no .gitattributes. Git for Windows defaults to core.autocrlf=true, so a clone made on Windows gets CRLF line endings in every text file — including the shebang of every POSIX shell script. The build documented in docs/COMPILATION.MD and the local-source Docker build in docker/README.md then fail before compiling anything.
CONTRIBUTING.md asks contributors to "Commit Unix line endings", but nothing in the repo enforces it.
Reproduction
Clone with Git's default Windows setting and run the project's own pre-build step:
git -c core.autocrlf=true clone --depth 1 https://github.com/CCExtractor/ccextractor.git
cd ccextractor/linux
file pre-build.sh
# pre-build.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
head -1 pre-build.sh | cat -A
# #!/usr/bin/env bash^M$
Then run it under Linux (directly, in WSL, or in any container — this is what docker/Dockerfile does at step RUN ./pre-build.sh):
$ ./pre-build.sh
/usr/bin/env: 'bash\r': No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
exit=127
Normalising just that one file to LF makes it exit 0, so the line endings are the whole cause.
I hit this myself: docker build --build-arg USE_LOCAL_SOURCE=1 -f docker/Dockerfile . on a Windows checkout fails at
ERROR: process "/bin/sh -c ./pre-build.sh" did not complete successfully: exit code: 127
Affected files
16 tracked files carry a POSIX shebang and would be corrupted:
linux/autogen.sh linux/build linux/build_appimage.sh
linux/build_hardsubx linux/builddebug linux/cleanup
linux/module_generator linux/pre-build.sh mac/autogen.sh
mac/build.command mac/cleanup mac/gui/src/script.sh
mac/pre-build.sh package_creators/{arch,debian,rpm,tarball}.sh
snap/local/run-ccextractor.sh
Suggested fix
Add a .gitattributes pinning those to eol=lf (and the Windows .bat/.ps1 to eol=crlf).
Worth being explicit about one thing: not * text=auto. 978 tracked files are currently committed with CRLF, so a blanket rule would be a repo-wide renormalisation unrelated to this bug. A narrow rule changes no tracked file content — I verified that with git add --renormalize.
PR follows.
- Dominant language
- C
- Stars
- 901
- Forks
- 592
- Avg merge
- 7d 23h
- Merged PRs (30d)
- 11
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CCExtractor/ccextractor
-
[BUG] Legacy options -608, -708, -90090, -UCLA, -CC2, -LF, -DF, -parsepat, -parsepmt still rejected after #1856Possibly taken @Deepak-negi11 claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
CCExtractor/ccextractor#2367 ·
Maintainers usually reply within 1 day
-
[BUG] Memory leak in free_sub_track(): blockaddition and message buffer never freed for WebVTT tracksPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 86/100
CCExtractor/ccextractor#2247 ·
Maintainers usually reply within 1 day
-
`--out=mcc`: CDP cc_count field overflows above 31 triplets; uint8 `data_size` corrupts lengths and over-reads at higher countsPossibly taken @kaihere14 claimed this 8 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 72/100
CCExtractor/ccextractor#2365 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
CCExtractor/ccextractor#2358 · 1 comment ·
Maintainers usually reply within 1 day
-
--tpages-all extracts less than --tpagePossibly taken @SajalDevX claimed this 16 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 65/100
CCExtractor/ccextractor#2355 ·
Maintainers usually reply within 1 day
All issues in CCExtractor/ccextractor
Similar issues
-
good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
tmewett/BrogueCE#929 · 1 comment ·
Maintainers usually reply within 1 day
-
bug : find_key() compares kty against "ocy" instead of "oct", breaking kid-less HS256 verificationOpen
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
OpenPrinting/cups#1756 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 76/100
SteamGridDB/SGDBoop#147 ·