「du-sh*」と「du-sh./*」の違いは？

du -sh *の違いは何ですかおよびdu-sh ./* ？

注：私が興味を持っているのは *ですおよび./* パーツ。

承認された回答：

$ touch ./-c $'an12tb' foo
$ du -hs *
0       a
12      b
0       foo
0       total

ご覧のとおり、 -c ファイルはduのオプションとして使用されました報告されません（ totalが表示されます du -cのための行）。また、 an12tbというファイル aというファイルがあると思わせていますおよびb 。

$ du -hs -- *
0       a
12      b
0       -c
0       foo

それが良いです。少なくとも今回は-c オプションとしては使用されません。

$ du -hs ./*
0       ./a
12      b
0       ./-c
0       ./foo

それはさらに良いです。 ./ プレフィックスは-cを防ぎますオプションとして採用され、 ./が存在しないことから bの前出力には、 bがないことを示していますそこにファイルがありますが、改行文字を含むファイルがあります（ただし、それに関する詳細については、以下を参照してください）。

./を使用することをお勧めします可能な場合はプレフィックスを付け、そうでない場合は任意のデータの場合は、常に使用：

cmd -- "$var"

または：

cmd -- $patterns

cmdの場合 -をサポートしていませんオプションの終了をマークするには、バグとして作成者に報告する必要があります（ただし、選択によって選択され、 echo のように文書化されている場合を除きます）。。

./ *の場合があります -の問題を解決しますしません。例：

awk -f file.awk -- *

a =b.txtというファイルがある場合は失敗します現在のディレクトリにあります（awk変数 aを設定します b.txtへファイルを処理するように指示する代わりに）

awk -f file.awk ./*

./ a なので、問題はありませんは有効なawk変数名ではないため、 ./ a =b.txt 変数の割り当てとは見なされません。

cat -- * | wc -l

-というファイルがあると失敗します cat に示されているように、現在のディレクトリにあります stdinから読み取る（- ほとんどのテキスト処理ユーティリティとcdに特別です / pushd 。

cat ./* | wc -l

./-なので、OKです catに特別なことではありません。

のようなもの：

grep -l -- foo *.txt | wc -l

fooを含むファイルの数をカウントしますファイル名に改行文字が含まれていないことを前提としているため、間違っています（ wc -l </ code> grepによって出力された改行文字をカウントします各ファイルおよびファイル名自体のファイル）。代わりに使用する必要があります：

 grep -l foo ./*.txt | grep -c /
 
 （ /の数を数える ファイル名ごとに1つしか存在できないため、文字の信頼性が高くなります。
 
 再帰的なgrepの場合 、同等のトリックは次を使用することです：
 grep -rl foo .//. | grep -c //
 
  ./ *  ただし、望ましくない副作用が発生する可能性があります。
 cat ./*
 
 ファイルごとにさらに2文字を追加するため、引数と環境の最大サイズの制限に早く到達するようになります。また、その ./が不要な場合もあります 出力で報告されます。いいね：
 grep foo ./*
 
 出力します：
 ./a.txt: foobar
 
 代わりに：
 a.txt: foobar
 さらなる余談
 
 。コメントでの議論に続いて、ここでそれを拡張する必要があるように感じます。
 $ du -hs ./*
0       ./a
12      b
0       ./-c
0       ./foo
 
 上記、その ./  各ファイルの先頭をマークすることは、各ファイル名がどこから始まるかを明確に識別できることを意味します（ ./  ）およびそれが終了する場所（次の ./の前の改行で または出力の終わり）。
 関連：GOPATHの最初のディレクトリのbinサブディレクトリをPATHに追加するにはどうすればよいですか？ 
 つまり、 du./*の出力は 、 du-*とは逆に ）スクリプトではそれほど簡単ではありませんが、確実に解析できます。
 
 ただし、出力が端末に送られる場合、ファイル名にだまされる可能性のある方法は他にもたくさんあります。
   
 制御文字、エスケープシーケンスは、表示方法に影響を与える可能性があります。たとえば、 r  カーソルを行の先頭bに移動します カーソルを後ろに移動します。e[C  転送（ほとんどの端末で）…
 
  
 最も明白な文字であるスペース文字から始まる多くの文字は、端末では表示されません。
 
  
 ほとんどのフォントのスラッシュとまったく同じように見えるUnicode文字があります
  $ printf 'u002f u2044 u2215 u2571 u29F8n'
 / ⁄ ∕ ╱ ⧸
 
 
 
 （ブラウザでどのように表示されるかを確認してください。）
 
 例：
 $ touch x 'x ' $'ybx' $'xn0t.u2215x' $'yr0t.e[Cx'
$ ln x y
$ du -hs ./*
0       ./x
0       ./x
0       ./x
0       .∕x
0       ./x
0       ./x
 
 たくさんのx のがy 行方不明です。
 
  GNUのようないくつかのツール lsは、印刷できない文字を疑問符に置き換えます（ ∕ に注意してください） （U + 2215）は印刷可能ですが）出力が端末に送られるとき。 GNU  du  しません。
 
 それらを明らかにする方法があります：
 $ ls
x  x   x?0?.∕x  y  y?0?.?[Cx  y?x
$ LC_ALL=C ls
x  x?0?.???x  x   y  y?x  y?0?.?[Cx
 
  ∕の方法をご覧ください  ???になりました  lsに伝えた後 文字セットがASCIIであったこと。
   $ du -hs ./* | LC_ALL =C sed -n l0t./x$0t./x $0t./x$0t.342210225x$0t./yr0t。