Simple question - is there an easy way to disable the end-of-file use of
#27 in BP (Dos)? I know that I can use binary mode, but I'd rather not.
(The #27 character occurs in a text file as a left-arrow, and of-course
my software currently aborts when it is met.)

I'm sure I've seen some way of telling the library textfile code to
ignore #27 (or perhaps set it to something else) but I can't remember
what it was - perhaps it was all a dream.

However, I've been looking through the RTL code, and the only places that
"eof" is used appear to be hard-coded, so it looks like I'm left with
rewriting my code to work with binary files (this looks most likely), or
else putting up with the problem. (I don't fancy patching the RTL, and in
any case I suspect that a lot of the problem is internal to DOS so an RTL
patch wouldn't fix the problem.)

I suppose I could redefine some other chars (#16 and #17 seem good
candidates) to look like the #26/#27 arrow characters on screen, but that
isn't really solving the problem; it would mean that the input file has
to be written by someone aware of the limitations.

The problem with disabling the EOF (#26) character is that the function
Eof(F: File): boolean checks specifically for that character (as far as I
remember). Generally, if you have files that have an EOF in them, they
*are* binary files and need to be treated as such. I've just recently written
programs which search for an Esc (#27), though, so I know that TP
doesn't have any problem with them. (You are correct about it appearing
as a left-arrow, but that character doesn't cause TP to generate an EOF).

[Multilingual sig deleted]