Re^3: regex to add network line-endings if required.

I would do that this way:

s/\015\012|\012\015|\012|\015/\015\012/g;
[download]

Update: I got that order wrong, as BrowserUk suggests. I had the shorter versions on the left, and the longer on the right. The above is fixed.

It should help you with things like this to take a good, hard look at the perlre section of the standard Perl docs. You should have a copy of the standard Perl docs on your system, but if not, perlre is on search.cpan.org too.

Christopher E. Stith

Comment on Re^3: regex to add network line-endings if required. Download Code

Replies are listed 'Best First'.
Re^4: regex to add network line-endings if required. by BrowserUk (Patriarch) on Feb 15, 2005 at 19:00 UTC
Isn't that always going to match \012 in preference to \012\015? Also, from the way I read the OP, they are only interested in fixing line-endings; ie. those at the end of the string rather than any embedded, but I could be wrong on that. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]
Re^5: regex to add network line-endings if required. by mr_mischief (Monsignor) on Feb 15, 2005 at 20:27 UTC
I updated my original post to have the shorter versions after the longer ones, to alleviate the problem you mentioned of matching the "\012" instead of "\012\015". As for only needing line endings, since each of these could be the marker for a line ending, one could only know the difference if the source of the original line is known. In the case that one knows the line ending which needs to be fixed, one would only need to fix that type of line ending. Since multiple types of line endings need to be addressed, there must not be an idea of "end of line" within the strings themselves other than the line ending sequences. If there's some other way to know what is a line, via some outside data, then things could be different. The whole idea of what is a line according to the application in question may require more thought, but that information has not been provided here. Christopher E. Stith	[reply]