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問題を解決できます。しかし、奇妙に見えます。catddpv
これは包括的なバグですか、それともこれらのユーティリティがすべての入力を消費することを要求する標準がありますか？