[pwdisswordfish2]

That is a common misconception.

http://jdebp.info/FGA/dos-character-26-is-not-special.html

[unilynx]

I'm pretty sure the DOS TYPE command (its version of cat) would stop at the first ^Z it encountered, even if the file was longer.

It was sometimes used to have TYPE print something human readable and stop before the remaining (binary) file data would scroll everything away

[cesarb]

> It was sometimes used to have TYPE print something human readable and stop before the remaining (binary) file data would scroll everything away

Notably, in the PNG file format (created back when MS-DOS was still very relevant):

"The first eight bytes of a PNG file always contain the following values: [...] The control-Z character stops file display under MS-DOS. [...]" (http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R....)

[nineteen999]

Maybe not for DOS, but for CP/M it most certainly is true, since the length of a file in bytes is not stored anywhere. Only the number of (typically 128 byte) sectors.

For binary files, you just assume there is padding at the end of the file to the end of the sector. For text files, the SUB code was used to indicate where the file ended.

[tigershark]

It’s not true, plenty of DOS programs stopped I/O operations with ctrl + z, and exited with ctrl + c. What you are saying is that obviously there was no physical 1A byte to demarcate the end of the file, but 1A was used pretty much everywhere. And it’s actually a non printable character: https://en.m.wikipedia.org/wiki/Substitute_character So I’m missing the point of this article, CTRL Z and CTRL D are obviously non printable characters and of course they are not used anymore to demarcate the actual end of a file.