Add Option for EOL Normalization/Control
tajmone opened this issue · 6 comments
Feature request: add EOL normalization control option:
--eol=[cr|lf|crlf]
Rationale: I've integrated boxes in Sublime Text, following the instructions on the website, but the CR EOL creeps into the text ouput as binary character <0x0d> (Git then sees the document as a binary file).
This is most likely an issue with the FilterPipes Sublime Text package not taking care of EOLs, but it nevertheless brings up the issue of piping/redirecting boxes output in different contexts.
IMO, being able to enforce a specific EOL (overriding the OS native EOL) would be useful on Windows, especially when working with Bash for Windows or bridging the ouput of various tools across WSL (Windows Subsystem for Linux), where different tools might enforce/expect different EOLs.
Although one could just pipe the output through dos2unix/unix2dos, an integrated option would be preferable. It would also allow Linux users to emit Windows style EOLs in automated toolchains (e.g. appending boxes output to a file marked as text eol=crlf in .gitattributes).
A small option that could ultimately spare lots of headaches, without affecting backward compatibility in any way.
Thank you for sharing this idea, and also for providing the well-thought-out rationale.
I'll accept this feature request, because I see it's kinda the only feasible workaround for the broken FilterPipes Sublime plugin, and such things may happen for other editors as well, in which case at least boxes would still be usable.
Since we don't have long options, it may end up as -e [cr|lf|crlf] or something, but I suppose that would be ok.
but I suppose that would be ok.
That would be perfect!
Thanks.
I would also add 'nul' to that option as a EOL terminator!
many programs now use 'nul' in this way. (find, gnu-grep, etc)
I would also add 'nul' to that option as a EOL terminator!
I don't understand. Can you explain more, or give a concrete use case?
I would also add 'nul' to that option as a EOL terminator!
I'm not sure I understood your proposal.
Wouldn't the presence of a nul character (i.e. 0x00) in a text file make it a binary file? (i.e. most text processing tools would see it as a binary file, including Git)
Or maybe the nul EOL option you're referring to means something else in the context of these application.
The only possible use that comes to my mind is that a similar option would be useful for processing binary files, which might contain nul-terminated strings among the raw data — and greps' documentation the --null-data/-z option seems to confirm this:
-z
--null-data
Treat input and output data as sequences of lines, each terminated by a zero byte (the ASCII NUL character) instead of a newline. Like the-Zor--nulloption, this option can be used with commands like ‘sort -z’ to process arbitrary file names.
but this would hardly play out well with boxes, which expects text files as input.