[ BUG ] --insert writes LF line endings into a file with CRLF line endings
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 80/100
Research direction
Start with internal/core/usecase/insertmd/markers.go and trace how replaceBetweenMarkers handles line endings; the issue also says the same rule applies to --stdout (#95). Reproduce with the provided CRLF input, then check that inserted lines use CRLF when the start marker has a trailing \r, while other lines remain unchanged.
Written by the indexing model from the issue text.
Description
Describe the bug
In a file with CRLF line endings, --insert finds the markers, but every line it writes
between them ends with \n only, so the file ends up with mixed line endings. The Bash
version writes these lines with \r\n when the <!--ts--> line ends with \r
(ekalinin/github-markdown-toc#119, fixed in ekalinin/github-markdown-toc#195).
To Reproduce
printf '<!--ts-->\r\n<!--te-->\r\n\r\n# Title\r\n\r\n## Section\r\n' > crlf.md
gh-md-toc --insert --no-backup crlf.md
od -c crlf.md
Actual, line by line:
<!--ts-->\r\n
* [Title](#title)\n
* [Section](#section)\n
\n
<!-- Created by https://github.com/ekalinin/github-markdown-toc.go -->\n
<!-- Added by: <user>, at: <date> -->\n
<!--te-->\r\n
\r\n
# Title\r\n
\r\n
## Section\r\n
Expected behavior
When the <!--ts--> line ends with \r, every line written between the markers (the TOC
entries, the empty line and the footer lines) ends with \r\n. Otherwise they end with
\n, as now. All other lines are kept as they are.
Environment (please complete the following information):
- OS: macOS (darwin/arm64)
- Version: 2.0.1, current
master(dd680f7)
Additional context
replaceBetweenMarkers(internal/core/usecase/insertmd/markers.go) splits the file on
\nand joins the TOC block with\n. The marker lines already keep their\r.- The same rule applies to
--stdout(#95).
- Dominant language
- Go
- Stars
- 525
- Forks
- 89
- Avg merge
- 6m
- Merged PRs (30d)
- 1
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No 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 ekalinin/github-markdown-toc.go
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
All issues in ekalinin/github-markdown-toc.go
Similar issues
-
book-layout.spec fails when the similar-books rail holds other projects' booksPossibly taken @praetorianer777 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
praetorianer777/GoTome#373 ·
Maintainers usually reply within 1 day
-
/shutdown/ready can fail to return an HTTP response when readiness takes longer than the server write timeoutPossibly taken @floriankoch claimed this today. Opentriage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
envoyproxy/gateway#10562 ·
Maintainers usually reply within 1 day
-
Adding an LDAP group reports every search failure as "LDAP Group DN is not found"Possibly taken @Daksha1611 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100