Should be CRLF in .DO files
Closed this issue · 3 comments
I was getting ?DS Error when trying to LOAD the M100LE.DO file. It turns out it has UNIX style line endings (just line feeds). The Model 100 expects MS DOS style — Carriage Return + Line Feed — for DO files.
People who use TELCOM to transfer the file, won't notice a problem because TELCOM silently inserts the carriage return. However, other software will send the file verbatim. The solution to this is to add a carriage return before every line feed. This is easily done (presuming you've got a decent version of sed):
sed -i 's/$/\x0D/' M100LE.DO
Note that I tested the CRLF version with TELCOM and it works fine there, as well.
If your text editor can handle DOS style line endings, you may want to use that for M100LE.DO so that sed won't be necessary in the future.
[Sidenote: It turns out that, technically, it is the UNIX host I'm logged into via TELCOM that is silently converting LF to CRLF, not TELCOM itself.]
The same is true for the WL20XX.DO files. If the word lists are transferred verbatim, M100LE will start and find the word file, but then STOP and print Ok. The fix is also the same:
sed -i 's/$/\x0D/' *.DO
EDIT: Oops, it turns out that this solution does not work with TELCOM as it inserts blank lines into the file.
However the solution is trivial, just add this to skip blanks:
6028 IF TW$ = "" THEN 6020First up, THANK YOU for the detailed exploration of the files and the issue. I appreciate folk looking at my code and offering ways to improve :)
Now, on to the stuff...
re: the CRLF...
Thanks for the suggestion about the text editor. I realized early on in development that my default Mac text editor wasn't doing that. I'd then switched to TextMate which allows that option.
... as for the files ...
Interesting. I'm not seeing this (LF only) behaviour in the files extracted from the .zip / release version... I've downloaded and extracted the .zip to a folder, then uploaded sample files to an online hex editor (hexed.it) to review. Samples of the word files and the code files both show proper CRLF pairs.
I wonder if there is something going on with the file extraction? I'll need to test this...
The patch you applied to the .gitattributes has fixed the problem for me. I will close this, but feel free to reopen if you believe there is more that needs doing.