The term CRLF refers to Carriage Return (ASCII 13, \r ) Line Feed (ASCII 10, \n ). They're used to note the termination of a line, however, dealt with differently in today's popular Operating Systems.
Whereas Windows follows the original convention of a carriage return plus a line feed ( CRLF ) for line endings, operating systems like Linux and Mac use only the line feed ( LF ) character. The history of these two control characters dates back to the era of the typewriter.
text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux. text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows.
You can use the -b
option for sed to have it treat the file as binary. This will fix the problem with cygwin's sed on Windows.
Example: sed -b 's/foo/bar/'
If you wish to match the end of the line, remember to match, capture and copy the optional carriage return.
Example: sed -b 's/foo\(\r\?\)$/bar\1/'
From the sed man page:
-b --binary
This option is available on every platform, but is only effective where the operating system makes a distinction between text files and binary files. When such a distinction is made—as is the case for MS-DOS, Windows, Cygwin—text files are composed of lines separated by a carriage return and a line feed character, and sed does not see the ending CR. When this option is specified, sed will open input files in binary mode, thus not requesting this special processing and considering lines to end at a line feed.`
You could try to sub the \n
for \r\n
at the end of your existing script like so:
sed 's/foo/bar/;s/$/\r/'
or perhaps
sed -e 's/foo/bar/' -e 's/$/\r/'
If neither of the above two work, you'll have to consult the specific man page for your version of sed
to see if such an option exists. Note that the *nix versions of sed
do not alter the line terminators without being told to do so.
Another alternative is to use the cygwin
version of sed
which shouldn't have this undesirable behavior.
Alternatively, (the cygwin version of) perl -pe
doesn't seem to have this problem.
Gnuwin can be suppressed to mess up the newlines (win->unix) if you only specify the -b switch and redirect. Using the -i (inline) switch will mess it up.
E.g. sed.exe -b "s/\xFF\xFE//" c:\temp\in.csv > c:\temp\out.csv
I've found that sed-4.4.exe
from https://github.com/mbuilov/sed-windows is pure win as it
-b
mode-i
mode-z
mode with \0
delimeters instead of \n
which may be handy sometimes tooSee also list of sed options and list of all windows sed ports.
Note that gnuwin32 sed 4.2.1 does corrupt line endings in -bi
mode and doesn't have -z
mode at all.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With