Yet another tangentially related thing that took me hours to diagnose and understand, but is actually easy to solve...
In Model 100 BASIC, SAVE"COM:98N1E" is different in two regards from the UPLOAD feature within a TELCOM session:
Line endings are sent as CRLF, instead of the simple CR. With the stty icrnl setting we previously established as useful (and necessary for larger uploads), this means the data stream ends up with LFLF line endings on the host, indistinguishable from a text file upload with intentional empty lines. I solved this by also setting stty inlcr, which means the host receives LFCR line endings from BASIC, and I can then simply discard any leading CR from each line received.
Instead of just stopping the data stream, BASIC appends an ASCII 26 (SUBstitute) character to mean "end of file", just like the DOS convention for text files. With default TTY settings, this causes the host to suspend the reading process, and you have to reactivate it with fg it before you can finalize the upload. I solved this by remapping the suspend function to an unused control code with stty susp ^N. The receiving script can then safely deal with the ^Z character it read, and filter it out.
Both those TTY settings shouldn't interfere with anything else, so they could be put in .bash_profile along with the others.
And I expect that any data to be exchanged with a Model 100/200 would be plain-text anyway (or if it's other data, then at least encoded in a way that avoids the ASCII 0-31 range), so all that shuffling around of control characters shouldn't impact the payload.
I ended up doing a read loop in bash, instead of just catting to the destination file, to allow me to filter out things like this. While I was at it, I also made the script wait indefinitely for the first line of incoming data, but time out after 2 seconds for all subsequent lines. Which means that (as long as you only want to upload one file per run) the upload can terminate automatically, much more elegant than having to manually end it with ^D.
Once I've thoroughly tested and polished them, would you be interested in adding that stor script and its (simpler) retr counterpart to this project? Alternatively, I guess I could start my own project for those, as well as that character conversion C program... that would make it slightly harder to find but less of a maintenance burden for you ;-)
Maybe it would also make sense to split your lengthy readme into multiple separate files and have example files (like the suggested .bash_profile settings) as a separately downloadable file?
Yet another tangentially related thing that took me hours to diagnose and understand, but is actually easy to solve...
In Model 100 BASIC,
SAVE"COM:98N1E"is different in two regards from the UPLOAD feature within a TELCOM session:stty icrnlsetting we previously established as useful (and necessary for larger uploads), this means the data stream ends up with LFLF line endings on the host, indistinguishable from a text file upload with intentional empty lines. I solved this by also settingstty inlcr, which means the host receives LFCR line endings from BASIC, and I can then simply discard any leading CR from each line received.fgit before you can finalize the upload. I solved this by remapping the suspend function to an unused control code withstty susp ^N. The receiving script can then safely deal with the ^Z character it read, and filter it out.Both those TTY settings shouldn't interfere with anything else, so they could be put in .bash_profile along with the others.
And I expect that any data to be exchanged with a Model 100/200 would be plain-text anyway (or if it's other data, then at least encoded in a way that avoids the ASCII 0-31 range), so all that shuffling around of control characters shouldn't impact the payload.
I ended up doing a read loop in bash, instead of just catting to the destination file, to allow me to filter out things like this. While I was at it, I also made the script wait indefinitely for the first line of incoming data, but time out after 2 seconds for all subsequent lines. Which means that (as long as you only want to upload one file per run) the upload can terminate automatically, much more elegant than having to manually end it with ^D.
Once I've thoroughly tested and polished them, would you be interested in adding that
storscript and its (simpler)retrcounterpart to this project? Alternatively, I guess I could start my own project for those, as well as that character conversion C program... that would make it slightly harder to find but less of a maintenance burden for you ;-)Maybe it would also make sense to split your lengthy readme into multiple separate files and have example files (like the suggested .bash_profile settings) as a separately downloadable file?