Sublime Forum

Line endings regex does not match what the status bar reads

#1

Hello:

When I do a search using regex \r\n for line endings there are never any found even though the status bar reads that the file is Windows. The regex \n will return every found line ending in the same test example.

When a file is created by processes I have written it always shows in the status bar as Windows. Even in this event the line ending are never found by regex \r\n but will be found by \n

I use Windows 10 and I prefer using \n as a line ending

Questions:

  1. What makes the status bar read the file as a Windows file?

  2. How can the documents created be recognised as Unix files and not Windows?

    The key to understanding question 2 is to have a common idea of what created is as opposed to me opening the file editing and saving. If I open a new file and edit save the file; it will be a Unix file. Sublime here is all set to save as Unix if I save the file. When a file is created a process has manufactured the file and saved it. I open it from a folder and it is recognised as a Windows file even though the line ending can not be found by the regex \r\n unless I specifically replace all \n with \r\n

One more question:
When I specifically replace all \n with \r\n the line ending are visible as <0x0d>
This I do as a test not as a convention.
The question is “Where is this setting found that displays the line ending”
I ask as it will be useful later.

Note:
Since 2018 Microsoft has built-in compatibility for line endings.
https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/

Thanks in advance for your time and consideration, Gilly

0 Likes

#2

When Sublime loads files in, it determines what style of line ending they have (\n for Linux, \r\n for Windows and \r for older MacOS files) and remembers it. It then normalizes the loaded data in memory to always have the line endings be \n. Whenever the file is saved back to disk, it’s saved with the line endings that it originally had.

Among other things this is likely to facilitate not making the lives of plugin authors horrible by requiring everyone that wants to write code to look around in or modify the file to have to do checks to determine what the line endings look like.

This is also the reason why manually trying to insert a \r character shows you the <0x0d> glyph in the file; Sublime’s not using that character as a line delimiter, so it appears as a binary byte in the file.

The moral of the story is: assume all lines end in \n, and if you want the line endings to be different than what they are, change the setting in the status bar by clicking on it and choosing the convention you want, then save the file.

0 Likes

#3

Thank you OdatNurd!

I went back and made another test. I saved all originating files into Unix and used those for the tests. The status bar now reads Unix on the resulting files in that tests.

About the statement, “Whenever the file is saved back to disk, it’s saved with the line endings that it originally had” , I am unable to verify at this time as I must move forward in code not research. I try to open 2 of the files saved in SublimeText with notePad and the line endings appear as expected; and, with windows working compatibility for line endings as it is now I would not be able to see it unless I could take the text file into a windows app that I could then apply regular expression on.
IDK I have not given any thought at this time where these component for such a test would be.

In as much however the point of that test is moot as I can function without further insight and as such I thank you for your time and will mark this question as resolved.

Again, thanks for your time and consideration, It is very well appreciated!
Gilly

1 Like

#4

About the comment of my reply I would like to add that the component to test regular expressions in windows is Notepad++

‘About the statement, “Whenever the file is saved back to disk, it’s saved with the line endings that it originally had” , I am unable to verify at this time as I must move forward in code not research. I try to open 2 of the files saved in SublimeText with notePad and the line endings appear as expected; and, with windows working compatibility for line endings as it is now I would not be able to see it unless I could take the text file into a windows app that I could then apply regular expression on.
IDK I have not given any thought at this time where these component for such a test would be.’

0 Likes

#5

Hello OdatNurd:

So I get time to test this assumption, “Whenever the file is saved back to disk, it’s saved with the line endings that it originally had”

On a Windows system,
Create a new file and type some short lines for test. Save.
Open Notepad++ and Sublime Text 3.
Open that file in Notepad++ then use the Show All Characters button. The line endings are shown to be Windows style.
Go to Sublime Text and Save the same file go back to Notepad++ and the line endings are now shown as Unix style line endings.

At this point I can reverse the process by going back to the same file from disk, Save and then the back in Notepad++ the line ending show as Windows style.

This dialog here gets complicated at this point and is beyond the scope of Sublime Text as the interaction of the file system, Notepad++ and SublimeText will produce a variety of results include saving both line endings in the same file and locking the line ending type to a specific style which last beyond the deletion on the content but not as far as recreating the file from scratch. To reproduce that test create a second file equal to the first file and know that it is saved with Windows line endings then copy n paste into the second file while in Notepad++ and know the line ending there are unix and the line endings will not change into Windows style. However if the text is completely different after the copy n paste the line endings do change. In addition, while the line endings of the file maybe of Unix style Notepad++ will write windows line endings as I type into the file.

My intention was to verify how sublime saves line endings to disk on Windows now that windows will recognise either line ending.

I did not intend to explain anything beyond the scope of the original question it just seemed of interest.

BTW OdatNurd, Thanks for the wonderful tutorials!

1 Like