hollasch/eol

Convert file end-of-line encodings

eol's Issues

Add --help option

eol doesn't null terminate the eol buffer

I should probably convert this to use string or wstring.

Create release

Stop implicitly interpreting nulls as end-of-lines

Just discovered that CSV files can include nulls that should not be interpreted as end-of-lines. If nulls are to be interpreted as end-of-lines, then rely on explicit options to support this.

This would be a major version bump.

See #11

Support multiple line-end sequences

Forked from #11.

Add --version option

Verify eol preserves UTF-8 files with Windows pipes

Since eol works with stdin and stdout, ensure that UTF-8 files are handled properly. If not, create a new issue to allow input and output files specified on the command line.

Accept alternate line ending sequences

Issue #3 called for expansion of Unicode line-ending sequences. Better, do two things:

• Support multiple end-of-line sequences
• Support Unicode codepoint specifications (such as \x000a).

Add README

Convert to CMake

eol isn't properly recognizing \r\n sequences

Instead, it emits an EOL for \r and another one for \n.

Handle Unicode line endings

Currently eol only considers the following characters as line terminators:

• U+0000 (null)
• U+000a (linefeed / newline)
• U+000d (carriage return)

Add the following line terminators to the list:

• U+0085 (next line, UTF-8 = c2 85)
• U+2028 (line separator, UTF-8 = e2 80 a8)
• U+2029 (paragraph separator, UTF-8 = e2 80 a9)

eol should just assume UTF-8 encoding.

Add option to include final EOL if not present in original

That is, an option to append a final EOL when the last line of the input does not include an explicit EOL.