If I have a binary file with the following contents:
48 65 6C 6C 6F 1A 48 65 6C 6C 6F
Then when I run the TYPE command on it, it stops reading at the 1A character:
C:\Temp>type file.bin
Hello
However, when I run TYPE again but this time pipe the output to MORE, it produces the following output:
C:\Temp>type file.bin|more
Hello→Hello
C:\Temp>
Which is more representative of the actual contents of the file than the previous command.
What exactly does piping output to MORE do that makes it print out the entire ASCII representation of the file regardless of the presence of a 1A character?
type command checks internally where the output will be sent.
If the output stream is the console, the input buffer is checked for the presence of Ctrl-Z (0x1A character) that is handled as EOF.
If the output stream is not the console, then all the characters are handled. This happens not only with pipes, but also redirection.
type file.bin | more
type file.bin > con
type file.bin > file.bin.out
Both redirected and piped type commands will handle all the characters.
This behaviour of 0x1A character is also present in copy command, but in this case it is also documented.