`cat file` 是如何工作的？

Question

cat < file打印内容文件到标准输出。

cat > file读取 stdin 直到检测到Ctrl+D并将输入文本写入文件。

cat <> file，至少在我的 Bash 版本中，打印以下内容文件很高兴（没有错误），但不修改文件，也不更新修改时间戳。

Bash 标准如何证明>第三个语句中看似被忽略的内容是合理的 - 更重要的是，它是正在做任何事物？

Answer 1

Bash 使用<>来创建读写文件描述符:

重定向运算符

[n]<>word

导致打开名称为 word 扩展的文件，以便在文件描述符 n 上进行读写操作，如果未指定 n，则在文件描述符 0 上打开该文件。如果该文件不存在，则创建该文件。

cat <> file打开file读写并将其绑定到描述符 0（标准输入）。它本质上相当于< file任何合理编写的程序，因为通常没有人可能尝试写入标准输入，但如果有人这样做，它就能够做到。

您可以编写一个简单的 C 程序来直接测试它 -write(0, "hello", 6)将通过标准输入hello写入。file

<>应该也可以在任何其他兼容 POSIX 的 shell 中工作具有相同的效果。

Answer 2

<> file打开文件（默认在文件描述符 0 (stdin) 上，如<）读+写模式没有截断和如果文件事先不存在则创建该文件。

这对应于O_RDWR|O_CREAT传递给open()系统调用的标志。相比之下，<是O_RDONLY和>是O_WRONLY|O_CREAT|O_TRUNC和>> O_WRONLY|O_CREAT|O_APPEND。

让标准输入可写通常不太有用，因为应用程序通常不会写入其标准输入。应用程序通常不希望读取和写入它们在启动时收到的文件描述符；它们通常从 stdin（或它们自己打开的文件描述符）读取并写入 stdout 或 stderr（或它们自己打开的文件描述符）。

<>可以有它的用途：

• 如果您不希望命令在不存在时失败，那么您可能更喜欢cat <> file创建一个空的。cat < filefilefile

• 的非截断方面<>使得就地覆盖文件很有用。但在这种情况下，您通常不会在文件描述符 0 上使用它：

  printf xxx 1<> file
  

  将前 3 个字节替换file为xxx。

• 在某些系统（例如 Linux）上，<>在命名管道 (FIFO) 上打开命名管道而不阻塞（无需等待其他进程打开另一端），并确保管道结构保持活动状态。例如在：

  mkfifo pipe; sed 's/foo/bar/g' <> pipe
  

  sed处理来自写入它的任意数量的其他进程的传入数据，并且永远不会看到eof。