If a Windows-authored text file must enter a Unix-based build, replace its line endings as a file-wide CRLF-to-LF conversion on a copy. Do not begin by searching for visible paragraph marks. The useful pass condition is more concrete: the copy reopens with the same text order, zero CRLF endings, 24 LF endings, and LF recorded as its line-ending mode.
That is the operation tested here in Rune Studio. It does not establish selective replacement inside a file that mixes CRLF, LF, and bare CR endings.
The problem is invisible in ordinary reading
Consider incoming/chapter-01.txt. It contains 24 line-ending units and uses CRLF throughout. Its editor view looks normal, so a visual scan cannot tell you whether a conversion happened. A reliable check separates four measurements:
- content lines and paragraph order;
- line-ending mode;
- the number of CRLF and LF sequences;
- the byte-size change after saving.
CRLF uses two bytes per ending; LF uses one. With 24 endings, a pure CRLF-to-LF conversion reduces the file by 24 bytes while leaving the prose unchanged. A file ending with a final newline may be displayed as 25 lines, so do not treat “24 endings” and the editor’s line count as interchangeable.
A controlled conversion from start to reopen
Make one working copy
Leave incoming/chapter-01.txt untouched and copy it to work/chapter-01-lf.txt. Record UTF-8, CRLF, 24 endings, and the original byte size. The path matters: a technically correct conversion applied to the source file is still the wrong outcome if the source was meant to remain intact.
Set the whole copy to LF
Open work/chapter-01-lf.txt in Rune Studio and change the file-wide line-ending setting to LF. This is not a find-and-replace query for the literal characters \r\n. Before applying the change, check the active tab name and the destination path.
Save, close, and reopen
Apply the LF setting and save the copy. Close it, then reopen that same file from work/. Reopening is important because the unsaved editor state may already display the new setting even if the intended file was not written.
Recount the endings
Inspect the reopened copy. The tested 24-line specimen began with 24 CRLF endings. After the file-wide conversion, it contained zero CRLF endings and 24 LF endings, and Rune Studio reported LF as the line-ending mode.
Also compare the paragraph sequence and the byte-size difference. If the text changed, the encoding changed at the same time, or the byte difference cannot be explained by the 24 removed CR bytes, stop and compare the copy with its source.
A small record prevents a vague “looks fine”
For a real handoff, keep a row such as this:
| File | Before | After | Reopened |
|---|---|---|---|
work/chapter-01-lf.txt |
CRLF 24 | CRLF 0 / LF 24 | mode LF, text order unchanged |
This record answers the practical question that the editor view cannot: which file changed, and what persisted after reopening?
Where this method stops
A mixed file needs a separate decision. If it contains 18 CRLF, seven LF, and three CR endings, you must first decide whether the goal is total normalization or selective preservation. The observed Rune Studio result supports total file conversion only. It does not show a one-pass selective rule for mixed endings, semantic exceptions, every regular-expression feature, or binary replacement.
Rune Studio successfully converted the controlled copy and reproduced the expected counts after reopening. For your own file, use the same four checks—content order, ending counts, byte difference, and reopened mode—before accepting the result. If that is the workflow you need, review the current Rune Studio product details before trying it on a production copy.
