私はここにいくつかの欠点とバグがあるかもしれないことを認めていますgrepcidrが、ほとんどの私の推測は間違っていました。公平に言えば、この答えの一部も正しく理解されていませんが、私の意図は、構文や出力を処理するために異なるパラダイムを使用する場合、v2にもある程度有用性があることを指摘することでした。

grepcidr数ヶ月前からいくつかのファイアウォールスクリプトを使い始めたので、これについての理解はまだ初期段階です。しかし、私が収集したところによると、 grepcidrその効果はまったく同じではありませんgrep。特にこれまでの私の「精神的なマップ」によると、 `grepcidrは文字列（またはCIDR仕様）を含む入力ファイルで行を探さず、次のものを含む入力ファイルで行を探します。 はいCIDR仕様に含まれています。

つまり、grepは干し草の山で針を見つけることです。を使用するには、干し草の grepcidr山を提供し、grepcidrは干し草の山に含まれているすべての針を表示します。これはまだ少し緩いですが... grepcidrコマンドライン検索仕様のサブセット（間違ったサブセットかもしれません）であるファイル内のエントリを探します。

次のスクリプトを考えてみましょう。

#!/usr/bin/env bash

cat << EOF > list.txt
5.45.148.0/22
5.45.148.0/24
5.45.149.0/24
5.45.150.0/24
5.45.151.0/24
5.45.152.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
EOF

grepcidr -V

j=0

echo $((++j)): "Lines containing entries within 5.45.151.17 (/32)"
grepcidr 5.45.151.17 list.txt

echo $((++j)): "Lines containing entries in the same /24 as 5.45.151.17"
grepcidr 5.45.151.17/24 list.txt

echo $((++j)): "Lines that have no entries within 5.45.0.0/16"
grepcidr -v 5.45.0.0/16 list.txt

echo $((++j)): "Lines with entries within 5.45.151.17/31"
grepcidr 5.45.151.17/31 list.txt

出力：

grepcidr 2.0
Copyright (C) 2004 - 2014  Jem E. Berkes <[email protected]>

1: Lines containing entries within 5.45.151.17 (/32)
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
2: Lines containing entries in the same /24 as 5.45.151.17
5.45.151.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
3: Lines that have no entries within 5.45.0.0/16
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
4: Lines with entries within 5.45.151.17/31
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19

具体的な例では、grepcidr「この特定のIPはそのファイルに/ 32として表示されますか？」と質問します。いいえ、そうではありません。要求すると、IP が付いた /24 がファイルに表示され、はい、2 つの場所に表示されます。

# grepcidr 5.45.148.23 list.txt
# grepcidr 5.45.148.23/24 list.txt
5.45.148.0/22
5.45.148.0/24

はい。 V3はV2よりも改善される可能性が高いです。そして、多くのUnixとLinuxのディストリビューションがパッケージリポジトリを更新するのに良い日になるでしょう。しかし、それはV2が役に立たないという意味ではありません。出力からどのような結論を導くのか注意する必要があります。

修正する

「悪い」CIDR仕様を受け入れるために新しい-sフラグを追加した後も同じように見えます。私のテストケースは完全ではない可能性が高いです。

1: Lines containing entries within 5.45.151.17 (/32)
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
2: Lines containing entries in the same /24 as 5.45.151.17
5.45.151.0/24
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19
5.45.151.247
3: Lines that have no entries within 5.45.0.0/16
5.44.15.17
5.44.1.0/24
5.44.1.15
5.44.1.5
5.44.1.5/32
4: Lines with entries within 5.45.151.17/31
5.45.151.17
5.45.151.17 5.45.151.18 5.45.151.19

FWIW、V3では、特定のテストケースの動作は変更されていません。

# grepcidr -V
grepcidr 3.0
Parts copyright (C) 2004, 2005  Jem E. Berkes <[email protected]>

# grepcidr 5.45.148.23 list.txt

...このフラグを使用するように@RasoolZiafatyの提案に解決策があるようですが-D：

# grepcidr -D 5.45.148.23 list.txt
5.45.148.0/22
5.45.148.0/24

私をいつも恥ずかしくさせる1つの質問は、IP範囲が明示的にリストされているIPと同じではない理由です。

# cat input.txt 
5.45.148.3 5.45.148.4 5.45.148.5
5.45.148.3-5.45.148.5
# grepcidr -D 5.45.148.4 input.txt 
5.45.148.3 5.45.148.4 5.45.148.5

現在の動作は、コマンドラインの特定のIPがファイル行がそのIPを開始点または終了点として参照している場合にのみファイル行と一致するようです。たとえば、5.45.148.41行でしか見つかりませんが、while5.45.148.3または5.45.148.52行で一致します。