私は試しています shellcheck 。
私はそのようなものを持っています
basename "${OPENSSL}"
そして私は次の提案を得る
Use parameter expansion instead, such as ${var##*/}.
実用的な観点から見ると、違いはありません
$ export OPENSSL=/opt/local/bin/openssl
$ basename ${OPENSSL}
openssl
$ echo ${OPENSSL##*/}
openssl
basename
は POSIX仕様 に含まれているため、ベストプラクティスである必要がある理由はありません。ヒントはありますか?
それは効率ではなく、正確さです。 basename
は、改行を使用して、出力するファイル名を区切ります。通常、ファイル名を1つだけ渡すと、出力に末尾の改行が追加されます。ファイル名自体に改行が含まれている可能性があるため、これらのファイル名を正しく処理することは困難です。
人々が通常basename
を次のように使用するという事実により、さらに複雑になります:"$(basename "$file")"
。 $(command)
はallからcommand
の末尾の改行を削除するため、これはさらに困難になります。 _$file
_が改行で終わるというまれなケースを考えてみましょう。次に、basename
は余分な改行を追加しますが、"$(basename "$file")"
はboth改行を削除し、誤ったファイル名を残します。
basename
のもう1つの問題は、_$file
_が_-
_(ダッシュa.k.a.マイナス)で始まる場合、オプションとして解釈されることです。これは簡単に修正できます:$(basename -- "$file")
basename
を使用する堅牢な方法は次のとおりです。
_# A file with three trailing newlines.
file=$'/tmp/evil\n\n\n'
# Add an 'x' so we can tell where $file's newlines end and basename's begin.
file_x="$(basename -- "$file"; printf x)"
# Strip off two trailing characters: the 'x' added by us and the newline added by basename.
base="${file_x%??}"
_
別の方法は_${file##*/}
_を使用することです。これは簡単ですが、独自のバグがあります。特に、_$file
_が_/
_または_foo/
_である場合は誤りです。
shellcheck
の- ソースコード の関連行は次のとおりです。
checkNeedlessCommands (T_SimpleCommand id _ (w:_)) | w `isCommand` "dirname" =
style id "Use parameter expansion instead, such as ${var%/*}."
checkNeedlessCommands (T_SimpleCommand id _ (w:_)) | w `isCommand` "basename" =
style id "Use parameter expansion instead, such as ${var##*/}."
checkNeedlessCommands _ = return ()
明確な説明はありませんが、関数の名前(checkNeedlessCommands
)に基づいて、@ jordanmは完全に正しいように見え、新しいプロセスの分岐を回避することを示唆しています。
dirname
、basename
、readlink
など(@Marcoに感謝-これは修正されています)は、セキュリティが重要になると(パスのセキュリティが必要になる)移植性の問題を引き起こす可能性があります。多くのシステム(Fedora Linuxなど)は/bin
に配置しますが、他のシステム(Mac OSXなど)は/usr/bin
に配置します。次に、WindowsにはBashがあります(例:cygwin、msysなど)。 可能な場合は、常に純粋なBashを使用することをお勧めします。 (@Marcoコメントによる)
ところで、shellcheckへのポインタをありがとう、私は前にそれを見たことがありません。