TYPE命令在0x1A处停止，除非通过管道传递给MORE? [英] TYPE command stops on 0x1A, except when piped to MORE?

问题描述

如果我有一个包含以下内容的二进制文件:

If I have a binary file with the following contents:

48 65 6C 6C 6F 1A 48 65 6C 6C 6F

然后，当我在其上运行TYPE命令时，它会停止在1A字符处读取:

Then when I run the TYPE command on it, it stops reading at the 1A character:

C:\Temp>type file.bin
Hello

但是，当我再次运行TYPE但这一次将输出通过管道传输到MORE时，它将产生以下输出:

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.

管道输出到MORE的确切功能是什么，无论是否存在1A字符，它都能打印出文件的整个ASCII表示形式?

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命令在内部检查输出的发送位置.

type command checks internally where the output will be sent.

如果输出流是控制台，则检查输入缓冲区中是否存在作为EOF处理的 Ctrl-Z (0x1A字符).

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

重定向和管道传输的type命令都将处理所有字符.

Both redirected and piped type commands will handle all the characters.

此0x1A字符的行为也出现在copy命令中，但在这种情况下，它也是

This behaviour of 0x1A character is also present in copy command, but in this case it is also documented.

这篇关于TYPE命令在0x1A处停止，除非通过管道传递给MORE?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！