在 bash 中，该命令hexdump -C /dev/urandom > hexdump.txt不会终止。
即使文件系统已满，它也会无限期地继续下去。
read(0, "\326\210L0\rL<\177\207\214\3\2237\vi\315\232P\303\275\345\26jDy\272\262\233\304\340g\7"..., 4096) = 4096
write(1, " ac 78 78 bf 6e 54 de 64 c8 89 "..., 4096) = 4096
write(1, "[|\n012f40d0 1c 14 ea 0b 12 8a 9"..., 4096) = 4096
write(1, "M......Uo/9i1|\n012f4410 2c f8 3"..., 4096) = 4096
write(1, " 1a 7c |{...wSZq5/.{...||\n012f4"..., 4096) = -1 ENOSPC (No space left on device)
write(1, "25 fa d5 67 7a 93 |.=...j}V>.%."..., 4096) = -1 ENOSPC (No space left on device)
read(0, "\336&v\266I\10\254\3551\225\370\"^g\224\10\5\17h\tNkA.(\374\302\333`K/\332"..., 4096) = 4096
write(1, " ad 7a 3f 0c f4 0e a0 b8 8d |."..., 4096) = -1 ENOSPC (No space left on device)
write(1, "ab 1c f4 79 f1 49 20 0e a1 f3 7"..., 4096) = -1 ENOSPC (No space left on device)
如果它确实终止（当输入不是无限时），它仍然在最后报告写入错误......但到那时它已经完全消耗了输入，产生无数 ENOSPC 错误。
然后我测试了其他命令。busybox hexdump有同样的问题。od有同样的问题。strings有同样的问题...
那么这涉及到util-linux，coreutils，binutils，...？
我可以像这样解决这个问题，hexdump -C /dev/urandom | cat > hexdump.txt因为cat, dd,pv在写入错误时终止，这反过来又杀死了整个管道。但它看起来很奇怪。
这是一个全面的错误还是有一些标准要求这些实用程序必须消耗所有输入？