私はよくコマンドを使います
cat /dev/urandom | strings --bytes 1 | tr -d '\n\t ' | head --bytes 32
疑似ランダムパスワードを生成します。これはでは機能しません/dev/random。
具体的には
cat /dev/urandom | strings --bytes 1 | tr -d '\n\t ' 出力を生成しますcat /dev/random | strings --bytes 1 出力を生成しますcat /dev/random | strings --bytes 1 | tr -d '\n\t ' 出力を生成しません注意：使用/dev/randomする場合、エントロピーを生成するために、マウスを小刻みに動かすか、キー（Ctrl、Shiftなど）を押す必要がある場合があります。
最後の例が機能しないのはなぜですか？ないtrことを大きな内部バッファのいくつかの種類を持って/dev/urandomすぐに塗りつぶししかしが/dev/randomないのですか？
PS私はCentOS6.5を使用しています
cat /proc/version
Linux version 2.6.32-431.3.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Jan 3 21:39:27 UTC 2014
最終的にはそうなるでしょう。
に：
cat /dev/random | strings --bytes 1 | tr -d '\n\t '
cat バッファリングすることはありませんが、ここで連結するものがないため、とにかく不要です。
< /dev/random strings --bytes 1 | tr -d '\n\t '
stringsただし、その出力はもはやないため、端末は、出力が端末に送られるときに、ラインではなくブロック（4または8kBなど）によって出力をバッファリングします。
したがって、出力する4kB相当の文字が蓄積されたときにのみ、stdoutへの書き込みが開始されます。これに/dev/randomはしばらく時間がかかります。
tr出力は端末に送られるため（端末のシェルプロンプトで実行している場合）、出力は行ごとにバッファリングされます。を削除しているため\n、書き込む行が完全になることはありません。代わりに、ブロック全体が蓄積されるとすぐに書き込みます（出力が端末に送信されない場合など）。
したがって、8kB（2ブロックはおそらくはるかに多い）のデータを書き込むのに十分な量を読み取るtrまで、何も書き込まない可能性があります（最初のブロックには改行文字、タブ文字、またはスペース文字が含まれる可能性があるため）。strings/dev/random
私がこれを試しているこのシステムでは、/dev/random（の12MiBとは対照的に/dev/urandom）から1秒あたり平均3バイトを取得できるため、最良のシナリオ（からの最初の4096バイト/dev/randomはすべて印刷可能なものです）では、 22分前に話しているとtr何かが出力され始めます。しかし、それは数時間になる可能性が高いです（簡単なテストでは、strings1〜2ブロックの読み取りごとにブロックを書き込むことがわかり、出力ブロックには改行文字の約30％が含まれているため、読み取る必要があると思います少なくとも3ブロック前にtrは、出力する4096文字があります）。
これを回避するには、次のようにします。
< /dev/random stdbuf -o0 strings --bytes 1 | stdbuf -o0 tr -d '\n\t '
stdbuf LD_PRELOADトリックを介してコマンドのstdioバッファリングを変更するGNUコマンド（一部のBSDにもあります）です。
の代わりにstrings、tr -cd '[:graph:]'タブ、改行、スペースを除外するを使用できることに注意してください。
CUTF-8文字で将来起こりうる驚きを避けるために、ロケールもに修正することをお勧めします。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加