私は最近bash、STDINからの引数またはストリームを受け入れることができる（つまり、パイプで接続できる）関数を作成するというコンテキストで、この非常に優れた構文に出くわしました。表面的には、ここで何が起こっているのかは理解できますが、これがどのように機能するかについての実際のメカニズムについてもう少し説明したいと思います。
構文は次のとおりです（タイトルごと）： ${1:-$(</dev/stdin)}
そして、文脈において、それを次のように使用するかもしれません：
log(){
echo -e >&1 "INFO: ${1:-$(</dev/stdin)}"
}
次の使用を許可します。
$ log foo
INFO: foo
または、これを行うこともできます
mv -v foo.ext bar.ext | log
INFO: renamed 'foo.ext' -> 'bar.ext'
これは、引数とパイプの両方の機能をbash関数で有効にするために私が見た中で最も簡潔な方法であるため、素晴らしいです（残念ながら、今どこで遭遇したかを忘れています）。
今、私はここで起こっていることのほとんどを少なくとも表面的には理解しています（または理解していると思います）が、より深い理解をいただければ幸いです。これが私がそれをどのように解釈するかであり、その後に私の残りの質問が続きます：
${1:-$(</dev/stdin)}${1} 明らかに、関数が受け入れるデフォルトの引数です${1:-x}が空の場合（または設定されていない'x'場合）、変数/中括弧の展開は文字列に「フォールバック」し$1ます。この場合、STDINプロセスサブにフォールバックします。$()明らかに</dev/stdin明らかに標準入力からのリダイレクトであり、パイプがまったく機能することを可能にします。これは基本的に$1、引数が入力されていない場合は、STDINの使用にフォールバックすることを意味します。これは概念的には満足しています。
だからここに私の質問があります：
<内でリダイレクト（）を見たことがありませんが、$(cat < somefile.ext)）。では、$(.. )：bashのマニュアルからコマンド置換ではないプロセスsubstiutionです<(... )。およびコマンド置換からコマンド置換$（cat file）は、同等であるがより高速な$（<file）に置き換えることができます。
/dev/stdinシンボリックリンクである/proc/self/fd/0ための便利ここで、$(<..)ファイルを予期する構文。
stdinが閉じるまでコマンドがブロックされる可能性があるため、これにより問題が発生する可能性があります。auは二重引用符で囲まれているため、複数行の入力が保持されるという意味で安全です。
最後に、パイプを作成し、mv -v foo.ext bar.ext | logログコマンドごとにプロセスをフォークする（のように）のは非効率的かもしれません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加