なぜコマンド「ls | ファイル」の動作？

私はコマンドラインについて研究してきましたが、|（パイプライン）はコマンドからの出力を別のコマンドの入力にリダイレクトすることを意味しています。では、なぜコマンドls | fileが機能しないのですか？

file 入力は次のようなファイル名の1つです file filename1 filename2

ls出力はフォルダ上のディレクトリとファイルのリストなのでls | file、フォルダ上のすべてのファイルのファイルタイプを表示することになっていると思いました。

ただし、使用すると、出力は次のようになります。

    Usage: file [-bcEhikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type]
        [-e testname] [-F separator] [-f namefile] [-m magicfiles] file ...
    file -C [-m magicfiles]
    file [--help]

fileコマンドの使用に何らかのエラーがあったため

基本的な問題は、file標準入力ではなく、コマンドライン引数としてファイル名を想定していることです。を記述ls | fileすると、の出力がにls入力として渡されますfile。引数としてではなく、入力として。

違いは何ですか？

• コマンドライン引数は、コマンドの後にフラグやファイル名を書き込むときですcmd arg1 arg2 arg3。シェルスクリプトでは、これらの引数は変数として利用可能です$1、$2、$3あなたが経由でそれらにアクセスしたい、などでC char **argvおよびint argc引数へmain()。

• 標準入力のstdinは、データのストリームです。コマンドライン引数が与えられていない場合に、標準入力のようなプログラムcatまたはwc標準入力から読み取るプログラムもあります。シェルスクリプトではread、1行の入力を取得するために使用できます。C では、さまざまなオプションの中でscanf()またはを使用できgetchar()ます。

file通常、stdinからは読み取りません。少なくとも1つのファイル名が引数として渡されることを想定しています。ls | file引数を渡さなかったため、を記述するときに使用法を出力するのはこのためです。

のようxargsに、stdinを引数に変換するために使用できますls | xargs file。それでも、terdonが言及しているように、解析lsは悪い考えです。これを行う最も直接的な方法は単純です：

file *

あなたが言うように、の入力はfilenamesでfileなければならないからです。ただし、の出力は単なるテキストです。ファイル名のリストであっても、それが単なるテキストであり、ハードドライブ上のファイルの場所ではないという事実は変わりません。ls

画面に出力が印刷されると、表示されるのはテキストです。そのテキストが詩であるか、ファイル名のリストであるかは、コンピューターにとって違いはありません。知っているのは、それがテキストであることだけです。これが、lsテキストとして入力を受け取るプログラムにの出力を渡すことができる理由です（ただし、実際にはそうすべきではありません）。

$ ls / | grep etc
etc

そのため、ファイル名を取得するコマンドの入力として、ファイル名をテキスト（lsまたはなどfind）としてリストするコマンドの出力を使用するには、いくつかのトリックを使用する必要があります。これの典型的なツールはxargs次のとおりです。

$ ls
file1 file2

$ ls | xargs wc
 9  9 38 file1
 5  5 20 file2
14 14 58 total

前にも言ったように、あなたは本当にの出力を解析したくありませんls。以下のようなものがfind良いです（print0印刷物\0の代わりに、各ファイル名の後にnewilneと-0のはxargs、それは、そのような入力に対処することができます。これは、ファイル名は改行を含むとあなたのコマンドを機能させるためのトリックです）：

$ find . -type f -print0 | xargs -0 wc
 9  9 38 ./file1
 5  5 20 ./file2
14 14 58 total

これには、xargsまったく必要なく、これを行う独自の方法もあります：

$ find . -type f -exec wc {} +
 9  9 38 ./file1
 5  5 20 ./file2
14 14 58 total

最後に、シェルループを使用することもできます。ただし、ほとんどの場合、xargsはるかに高速で効率的になります。例えば：

$ for file in *; do wc "$file"; done
 9  9 38 file1
 5  5 20 file2

「|」ということを学びました （パイプライン）は、コマンドからの出力を別のコマンドの入力にリダイレクトするためのものです。

出力は「リダイレクト」されませんが、プログラムの出力を受け取り、入力として使用します。一方、ファイルは入力ではなくファイル名を引数として受け取り、テストされます。リダイレクトでは、これらのファイル名は引数として渡されず、パイプでも引数として渡されません。

あなたができることは、--files-fromテストしたいすべてのファイルをリストするファイルがある場合、オプションでファイルからファイル名を読み取ることです。そうでなければ、単にファイルへのパスを引数として渡します。

受け入れられた答えは、パイプコマンドがすぐに機能しない理由を説明し、file *コマンドを使用すると、シンプルで簡単なソリューションを提供します。

いつか便利になるかもしれない別の代替案を提案したいと思います。トリックはバックティック(`)文字を使用しています。バックティックについては、ここで詳しく説明します。つまり、バッククォートで囲まれたコマンドの出力を取得し、それを文字列として残りのコマンドに置き換えます。

そのfind `ls`ため、lsコマンドの出力を取得し、findコマンドの引数として置き換えます。これは、受け入れられているソリューションよりも長く複雑です。ただし、他の状況ではこのバリエーションが役立つ場合があります。

lsパイプ経由の出力は、各行を区切る0x0aのデータのブロック（つまり、改行文字）でありfile、これを1つのパラメーターとして取得します。

一般的なルールとして、決してls他のコマンドのデータソースを生成するために使用しないでください-いつか..にパイプされrmて、あなたは困っています！

ループを使用するfor i in *; do file "$i" ; doneことをお勧めします。これにより、必要な出力が予想どおりに生成されます。スペースを含むファイル名の場合、引用符があります。

パイプをfile使用してフィードする場合-fは、通常ファイル名が続くオプションを使用しますが、1つのハイフン-を使用してstdinから読み取ることもできます。

$ ls
cow.pdf  some.txt
$ ls | file -f -
cow.pdf:       PDF document, version 1.4
some.txt:        ASCII text

ハイフンを使用したトリックは、-多くの標準のコマンドラインユーティリティで機能します（ただし、場合によっては機能し--ます）ので、常に試してみる価値があります。

このツールxargははるかに強力であり、ほとんどの場合、引数リストが長すぎる場合にのみ必要です（詳細についてはこの投稿を参照してください）。

以下のようなコマンドを使用して動作します

ls | xargs file

私にとってはうまくいくでしょう

これも動作するはずです：

file $(ls)

ここでも説明されているように：https : //unix.stackexchange.com/questions/5778/whats-the-difference-between-stuff-and-stuff