Linuxは複数の連続したパス区切り文字（/ home //// username /// file）をどのように処理しますか？
私はpythonスクリプトでファイルの場所をscpサブプロセスに渡すスクリプトを作成しています。それで問題ありませんが、パスとファイル名を連結して、パスに二重の '/があります。複数のファイル区切り記号があってもbashは気にしないことは知っていますが、それがどのように正確に修正されるのか疑問に思っています。余分な/sを取り除くbashですか？それとも本当に重要ではないのですか？
連結中に余分な/sをチェックするために数行のコードを節約できるので、私は尋ねます。大した問題ではないことはわかっていますが、私も知りたいです。 cd //usrの代わりにcd /usrという行があるbashスクリプトがあります。これは、パスで複数の/sを使用することが重要である可能性があることを示唆しているようです
複数のスラッシュを使用でき、単一のスラッシュと同等です。 シングルUnix仕様（バージョン4） 、 基本定義§3.271パス名 から：「複数の連続するスラッシュは1つのスラッシュと同じであると見なされます。」
1つの例外があります。パス名が2つの連続する文字で始まる場合、先頭の文字に続く最初のコンポーネントは、実装定義の方法で解釈される場合があります。 （参照： 基本定義§4.13パス名の解決 ）。 Linux自体はこれを行いませんが、一部のアプリケーションは可能であり、他のUNIX系システムはそれを行います（Cygwinなど）。
パス名の末尾にある/は、パス名がディレクトリを参照するように強制します。 （ POSIX 1003.1-2001（Single Unix v4）base definition§4.11pathname resolution では、末尾の/は末尾の/.と同等です。 POSIX 1003.1- 2008（Single Unix v4）基本定義§4.1 存在しないディレクトリに対処するために、/.と同等にするための要件が削除されます（たとえば、mkdir foo/が機能する必要があるのに対し、mkdir foo/.はそうしません—変更については rationale を参照してください）。
ディレクトリエントリに作用するプログラムの場合、fooがディレクトリへのシンボリックリンクである場合、foo/を渡すと、プログラムはシンボリックリンクではなくディレクトリに作用します。
¹ これはパス名解決にのみ適用されることに注意してください。つまり、ファイルにアクセスする場合です。ファイル名の操作が異なる場合があります。たとえば、 basename および dirname は、末尾のスラッシュを無視します。
OSもそれを気にしていないようで、パスに//を指定して開く直接syscallでCプログラムを試したところです。
pythonライブラリ関数os.path.normpathを使用して正規化できます。これにより、文字列を調べて余分なものを探す必要がなくなります。他の言語にも同様の関数があります。
http://docs.python.org/library/os.path.html#os.path.normpath
私が見たすべてのUnixシステムでは、単一の/と同じですが、 nix標準 は、
連続する2つのスラッシュで始まるパス名は、実装で定義された方法で解釈される場合がありますが、2つを超えるスラッシュは単一のスラッシュとして扱われます。
そのため、システムによっては特別に処理される場合があります。 （一部の古いUnixバージョンでは、リモートファイルシステムアクセスに二重先行/を使用していましたが、それでも実行できるものがあるかもしれません。）
使用する - os.path.join Pythonで、複数のスラッシュを取得することはありません。文字列を連結してファイル名を自分で構築することは、貧弱と見なされますPythonスタイル。
違いはありません。
複数のスラッシュは無視されます（影響なし）。例：
ls -al //usr///////bin/sed
もちろん、tr -sを介してパスを渡すことにより、パスに複数の/（スラッシュ）が含まれる可能性があるパスを正規化できます。
NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)
...そして$NORMALIZEDを使用します
ただし、それは必要です。私が知っているように、適切なUNIXカーネルは並行パス区切り文字を無視する必要があります---または概念的には..././...として扱います.