10

Python プログラムのすべてのパスで ".." (親ディレクトリの場合) と / (パス コンポーネントの区切りの場合) を使用して、プラットフォームに関係なく機能することはできますか?

一方では、ドキュメントでそのような主張を見たことがなく (見落としている可能性があります)、os および os.path モジュールは、プラットフォームに依存しない方法でパスを処理するための機能を提供します (os.pardir、os.path.参加してください…）、彼らがここにいるのには理由があると思います。

一方、「../path/to/file」はすべてのプラットフォームで機能する ことを StackOverflow で読むことができます…</p>

では、移植性のために os.pardir、os.path.join およびその仲間を常に使用する必要がありますか?それとも Unix パス名は常に安全ですか? それとも「ほぼ常に」安全 (つまり、Windows、OS X、および Linux で動作) でしょうか?

4

7 に答える 7

11

を使用して問題が発生したことはありませんが、 os.path.abspath..を使用して絶対パスに変換することをお勧めします。次に、可能な限り常に os.path.join を使用することをお勧めします。パスの結合には (移植性の問題は別として) 多くの特殊なケースがあり、それらについて心配する必要がないのは良いことです。例えば：

>>> '/foo/bar/' + 'qux'
'/foo/bar/qux'
>>> '/foo/bar' + 'qux'
'/foo/barqux'
>>> from os.path import join
>>> join('/foo/bar/', 'qux')
'/foo/bar/qux'
>>> join('/foo/bar', 'qux')
'/foo/bar/qux'

..あいまいなプラットフォームを使用している場合は、使用中に問題が発生する可能性がありますが、名前を付けることはできません (Windows、* nix、および OS X はすべてその表記法をサポートしています)。

于 2009-10-27T21:13:19.047 に答える
6

「ほぼ常に安全」が正しいです。あなたが関心を持っているすべてのプラットフォームはおそらく今日問題なく動作し、私は彼らがすぐに規約を変更するとは思わない.

ただし、Python は非常に移植性が高く、通常のプラットフォームよりもはるかに多くのプラットフォームで実行できます。モジュールの理由はos、プラットフォームが異なる要件を持っていることをスムーズにするのに役立つことです。

os関数を使用しない正当な理由はありますか?

os.pardirは自己文書化".."ですが、そうではありません.os.pardirはgrepしやすいかもしれません

これは、Macがまだすべての点で異なっていたときのpython 1.6のドキュメントです。

使用しているシステムに応じて、Mac、DOS、NT、または Posix 用の OS ルーチン。

これは以下をエクスポートします: - posix、nt、dos、os2、mac、または ce からのすべての関数 (unlink、stat など) - os.path はモジュール posixpath、ntpath、macpath、または dospath のいずれかです - os.name は ' posix'、'nt'、'dos'、'os2'、'mac'、または 'ce' - os.curdir は現在のディレクトリを表す文字列です ('.' または ':') - os.pardir は文字列です親ディレクトリを表す ('..' または '::') - os.sep は (または最も一般的な) パス名区切り記号 ('/' または ':' または '\') です - os.altsep は代替パス名ですセパレーター (なしまたは '/') - os.pathsep は $PATH などで使用されるコンポーネント セパレーターです - os.linesep はテキスト ファイルの行セパレーターです (' ' または ' ' または ' ') - os.defpath はデフォルトの検索です実行可能ファイルのパス

「os」をインポートして使用するプログラムは、異なるプラットフォーム間で移植できる可能性が高くなります。もちろん、すべてのプラットフォームで定義されている関数のみを使用し (unlink や opendir など)、パス名の操作はすべて os.path に任せる必要があります (split や join など)。

于 2009-10-27T21:48:56.083 に答える
3

Python 内では、 using/は常に機能します。サブシェルでコマンドを実行する場合は、OS の規則に注意する必要があります。

myprog = "/path/to/my/program"
os.system([myprog, "-n"])                           # 1
os.system([myprog, "C:/input/file/to/myprog"])      # 2

コマンド #1 はおそらく期待どおりに機能します。
コマンド #2 がmyprogWindows コマンドであり、そのコマンド ライン引数を解析して Windows ファイル名を取得することを想定している場合、コマンド #2 は機能しない可能性があります。

于 2009-10-27T21:12:40.920 に答える
3

Windows は/、パス区切りとしてサポートしています。Unix ファイル名と Windows ファイル名の間の唯一の非互換性は次のとおりです。

  • ファイル名に使用できる文字
  • 特別な名前と
  • 大文字と小文字の区別

Windows では、最初の 2 つのアカウントがより制限されています(つまり、より多くの禁止文字とより特殊な名前が使用されています)。一方、Unix では通常、大文字と小文字が区別されます。ここには、これらのキャラクターと名前が何であるかを正確にリストしたいくつかの回答があります。私はそれらを見つけることができるかどうかを確認します。

さて、開発環境にパスを作成または操作する機能が付属している場合は、それを使用する必要があります。それには理由があります。Windows や Unix よりもはるかに多くのプラットフォームがあることを考えると特にそうです。

最初の質問に答える../dir/fileと、上記の非互換性のいくつかに該当しない限り、はい動作します。

于 2009-10-27T21:12:50.887 に答える
3

これは Windows で動作するため、「どのプラットフォームでも」を Unix と Windows と定義しても問題ありません。

一方、Python は、VMS、RISC OS、およびまったく異なるファイル名規則を使用するその他の奇妙なプラットフォームでも実行されます。ただし、アプリケーションを VMS で実行させようとするのは、盲目的である可能性があります。「時期尚早の移植性は、比較的小さな悪の根源です」

いずれにせよ、私は os.path 関数を使用するのが好きです。それらは意図を表現するのに適しているからです。何百万もの目的のために実行される可能性のある単なる文字列の連結ではなく、パス操作として非常に明示的に読み取ります。

于 2009-10-27T21:16:30.600 に答える
1

OS/X と Linux はどちらも Unix と互換性があるため、定義上、質問の冒頭で指定した形式を使用します。Windows では、"\" に加えて "/" を使用できるため、Microsoft がずっと前に試していた Unix の亜種である Xenix とプログラムを交換することができ、その互換性は現在まで引き継がれています。したがって、それも機能します。

Python が他にいくつのプラットフォームに移植されたかはわかりませんし、それらについて話すこともできません。

于 2009-10-27T21:12:14.400 に答える
0

他の人が言ったように、スラッシュはすべての場合に機能しますが、パス セグメントのリストを作成し、それらを os.path.join() する方がよいでしょう。

于 2009-10-27T21:19:00.033 に答える