From be6f888c9e16a8177a361cbc1bdd1a41b4922ec4 Mon Sep 17 00:00:00 2001 From: Jon Foster Date: Wed, 6 Oct 2021 10:50:38 -0700 Subject: [PATCH] LINE INPUT control code fix #1 In all the dialects I've worked with I've never seen LINE INPUT alter anything but EOL characters on input. The only thing it did with EOL was stop and leave them out of the resulting string. This is fixes that issue but it needs further scrutiny to see if it breaks anything else and / or if a similar patch is needed somewhere else. I can now count the number of times a line is started with a tab!! 8-) --- bwb_inp.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/bwb_inp.c b/bwb_inp.c index 795c7fc..3b6f934 100644 --- a/bwb_inp.c +++ b/bwb_inp.c @@ -2776,7 +2776,25 @@ bwb_LINE_INPUT (LineType * Line) if (fgets (tbuf, tlen, My->CurrentFile->cfp)) /* bwb_LINE_INPUT */ { tbuf[tlen] = NulChar; - CleanTextInput (tbuf); + /* jaf-20211006 CleanTextInput() converts all <' ' chars to ' '. None of + the dialects I've used did this with `LINE INPUT ...` You could read a + whole file, verbatim, control codes and all (other than EOL), assuming + it had line breaks frequently enough. I was just going to patch + CleanTextInput, but it appears it may have valid uses in other + contexts. So lets replace the call to it with a simple EOL filter. + Depending on OS and compiler and since we're not opening files in + "text" mode we'll strip off up to two CRs or LFs. This means that CRLF + endings will be handled the same as LF, even on UNIX. I don't think + this will cause problems... I think its an advantage. + //CleanTextInput (tbuf); */ + tlen=strlen(tbuf); + if(tlen--) { + if(tbuf[tlen]=='\r' || tbuf[tlen]=='\n') { + tlen--; + if(tlen>=0 && (tbuf[tlen]=='\r' || tbuf[tlen]=='\n')) tlen--; + tbuf[tlen+1] = NulChar; + } + } } else {