Community

the wild edit help claims that \n is newline (as it is in test pad) but

replace: something\n

with: somethingelse\n

finds no instances of something\n even though they exist

The lines of a text file are terminated (or separated) by newlines (line breaks). The newline is a logical character, not a physical one, and its physical representation differs between systems. All ASCII-based systems use a combination of carriage return (CR: 0x0D) and line feed (LF: 0x0A). Unix and Unix-like systems use just LF; pre-Unix Mac systems use just CR; for reasons of ancient history (to do with the way 1950s Teletype machines worked), DOS and Windows systems use the two-character sequence CR, LF.

WildEdit's help is wrong: in WildEdit (as in Java, but not as in C, C++, Perl, Python, etc.) \n does not represent the logical newline character; it represents the physical line feed character. \r represents the physical carriage return character.

Therefore, WildEdit is fussy about line endings. If a file has DOS/Windows line endings, you must explicitly match the CR: use \r\n instead of \n. If you want the search expression to work for Unix line endings as well, use \r?\n.

This is unhelpful behaviour on the part of WildEdit. The newlines are not part of the text in a plain text document. Almost always, a user manipulating a text file has no interest in the physical representation in that file of the breaks between its lines.

That is very clear and helpful ben_josephs.

Thank you.

You're welcome. I'm glad it helped.