[ BUG ] --insert writes LF line endings into a file with CRLF line endings
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 80/100
Direzione di ricerca
Inizia da internal/core/usecase/insertmd/markers.go e segui come replaceBetweenMarkers gestisce i fine riga; l’issue dice anche che la stessa regola si applica a --stdout (#95). Riproduci il problema con l’input CRLF fornito, poi verifica che le righe inserite usino CRLF quando il marcatore iniziale termina con \r, mentre le altre righe restano invariate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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).
- Lingua principale
- Go
- Stelle
- 525
- Fork
- 89
- Merge medio
- 6m
- PR unite (30g)
- 1
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ekalinin/github-markdown-toc.go
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Tutte le issue di ekalinin/github-markdown-toc.go
Issue simili
-
/shutdown/ready can fail to return an HTTP response when readiness takes longer than the server write timeoutForse già presa @floriankoch l’ha presa oggi. Apertatriage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
envoyproxy/gateway#10562 ·
I maintainer di solito rispondono entro 1 giorno
-
Adding an LDAP group reports every search failure as "LDAP Group DN is not found"Forse già presa @Daksha1611 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
[Bug] K8s reconcile still resets explicit 0 to defaults for response_api, memory and flow stateForse già presa @Bevisy l’ha presa oggi. Apertaneeds-acceptance
Difficoltà 2/5 1-3 ore Idoneità per principianti 87/100
vllm-project/semantic-router#5998 ·
I maintainer di solito rispondono entro 2 giorni