On 3/27/2017 6:40 PM, Byron Sanchez wrote:
That was it!
I ran the command and received the output:
Starts with UTF-8 BOM: no
Starts with UTF-16 BOM: no
Looks like UTF-8: no
Has flag LOOK_NUL: yes
Has flag LOOK_CR: no
Has flag LOOK_LONE_CR: no
Has flag LOOK_LF: yes
Has flag LOOK_LONE_LF: yes
Has flag LOOK_CRLF: no
Has flag LOOK_LONG: no
Has flag LOOK_INVALID: no
Has flag LOOK_ODD: no
Has flag LOOK_SHORT: no
I deleted the null characters. I didn't have to address any of the
other flags in my case, just the null characters. After that, fossil
recognized the file as plain text again.
Unexpected NUL characters in a field of normal text will definitely
cause fossil to treat a file as binary.
If you really do need to store a NUL byte in a text file (as some sort
of delimiter, perhaps) fossil permits the over-long two byte UTF-8
encoding 0xC0 0x80 even though that is a technical violation of the
UTF-8 specification. Allowing that particular over-long encoding is a
common extension of UTF-8.
The other flags just indicate that you have normal *nix line endings
rather than CR LF endings used by DOS and Windows (and many many older
systems) or the CR only endings used by older Macs.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
