GCCクロスコンパイラの特定のバージョンを構築するためのスクリプトがあります。スクリプト全体には、繰り返されるパス区切り文字（/xxx/foo//bar/yyy）や途中の「this」ディレクトリ（）など、正規形式ではないパスがたくさんあります/xxx/foo/./bar/yyy。
私はそれらをすべて正規化する予定ですが、スクリプトが衛生化されていない場合を超えてフォームが重要かどうか疑問に思います。上記の形式に加えて、パスに "upディレクトリ"を含めることが特定の場合（たとえば "代わりに/xxx/foo/../bar/yyy" /xxx/bar/yyy）にも重要かどうか疑問に思います。たとえば、私は/xxx/foo/.//bar/yyy。
私が考えることができる唯一の状況は、リンクが関係している場合です。フォームが異なる動作をする可能性があると想像できますが、上記..の他の2つのフォームはどうですか？
たぶん、このようにルートを構築するプラットフォーム固有の理由があるかもしれません。
ベストアンサー1
/./常に競合が発生する必要があります/。
//一般的には折りたたむことができるはずですが、設定スクリプトでこれをチェックするのを見たことがあるので、他のシステムがある可能性があるとします。確認してみてください。しかし、おそらく大丈夫でしょう。
/../古いディレクトリがシンボリックリンクではない場合にのみ機能します（またはハードリンクではないと思います）。親ディレクトリへのハードリンクなので、..使用したテキストパスの分岐ではなく、その分岐に移動します。 （シェルはcdsのシンボリックリンクを解決しないように設定されている可能性があります。この場合、シンボリックリンクがあるディレクトリに移動します。ただし、この動作はほぼ完全にcdこのオプションが設定されているシェルに制限されます。）
を使用すると、readlink -f "$path"これらすべての状況が適切に解決されると信じています。