How do you tell whether a text file is using carriage returns or line feeds

1

In the linked topic, Dave, is using a ¶ character identical to using cr()?
How are cr() and lf() different?
If one has a text file, how can you know if line ends with lf() or cr()?
Tom

2

lf() is chr(10) and cr() is chr(13), so that’s how the characters themselves differ. One is 00001010 in binary, and the other is 00001101. To check manually, you could highlight and copy a portion of the text that includes a line ending, and then look at the result of hexstr(clipboard()). A linefeed will be 0A and a carriage return will be 0D. If you need to find out on the fly, you could use arraysize( with each character as the separator. If one returns 1, and the other a larger number, the larger number is the one in use.

In most cases, you may just want to convert blindly to the one you prefer. If you like line feeds, you could go with replace(replace(text,crlf(),lf()),cr(),lf()). That would first convert the windows crlf (chr(13)+chr(10)) line ending to the UNIX line feed. Then it would convert the classic Macintosh carriage return to line feeds.

Dave

3

It looks like I need to amend that. In Panorama X, the formula needs to be hexstr(texttobinary(clipboard())). In Panorama 6, that technique doesn’t work. It looks like Panorama 6 is looking at a clipboard flavor, where line feeds are converted automatically to carriage returns, so you will just get 0D either way.

Dave

4

Panorama X has pre-made functions to do this for you, see crtolf( and lftocr(.

5

Part of it anyway. There doesn’t seem to be one for converting the Windows crlf to either of the others.

6

What does the TextEditorObject use if some presses return for multiline data?

If appears to me that it is the lf().

7

Actually, both of these functions handle Windows crlf. In each case, any kind of line break is turned into the specified kind of line break.

For example, the lftocr() function will convert line feeds into carriage returns, but it will also convert Windows carriage return line feed pairs into carriage returns. Basically, whatever you hand it, you’ll get back carriage return delimited lines.

Here is the internal code for the lftocr() function:

replace(replace(thetext,crlf(),cr()),lf(),cr())

Important Note – In checking the code to publish here, I just realized that the crtolf() function in the 0.1.025 release is currently wrong, it converts to cr, not lf :frowning: I have just fixed it so that it correctly converts to lf, here is the fixed internal code for the crtolf() function:

replace(replace(thetext,crlf(),lf()),cr(),lf())
8

In Panorama X, it’s the line feed. In Panorama 6, it’s the carriage return. With a text editor object set to set a variable named theText, I put the formula hexstr(texttobinary(theText)) in a text display object. Then I typed

A
B

into the text editor, and the text display showed 410A42.

In Panorama 6, the formula was hexstr(theText), and the result was 410D42. 41 is the A. 42 is the B. 0A is the line feed, and 0D is the carriage return.

Dave

9

There’s apparently one more character getting into the act in Text Editors. I was getting errors on hfs paths converted to unix paths until I discovered the Text Editor was including a chr(127). Once I eliminated that the errors vanished.

10

I can’t figure out how to duplicate this. Can you give us an example?

11

Thanks for asking me for an example. I have egg on my face, but I’ll take it.

Apparently in this case it was un-wittingly self-inflicted twice, which lead me to believe Panorama was adding it. At least it has lead me to adding a useful character filter to the procedure.