現在の代替案は、ユーザーにパスの正規化を強制することです

PowerShellはすでに機能しており、パスを正規化する必要はありません。
ここでは、PowerShellは非常にユーザーフレンドリーです。ユーザーは、プラットフォームに関係なく快適なスラッシュを使用できます。
ベストプラクティスは、リテラルパスの使用を避け、パスコマンドレットを使用することです。

ベストプラクティスは、リテラルパスの使用を避け、パスコマンドレットを使用することです。

@iSazonovはい、いいえ。

もちろん、パスセグメントを組み合わせる場合は、パスコマンドレットを使用できます。 ただし、複数のセグメントを持つ相対パスを参照するスクリプトを作成していて、スクリプトがクロスプラットフォームで機能することを意図している場合は、そうするつもりはありません。

WindowsのPowerShell7プレビュー3では、タブ補完は円記号を使用してパスを補完します。 これは、PowerShellがクロスプラットフォームであるため、私たちが間違っていると思う場所の1つです。 少なくとも、タブ補完の一部としてWindowsで使用するディレクトリ区切り文字を選択するオプションが必要です： [System.IO.Path]::DirectorySeparatorCharまたは[System.IO.Path]::AltDirectorySeparatorChar 。 私たちが今日いる場所を考えると、クロスプラットフォームの作業を行うほとんどの人は、WindowsでデフォルトでAltDirectorySeparatorCharを使用するパスのタブ補完を望んでいると思いますが、私が知る限り、それを行う方法はありません。

@chriskuech ：パスのタブ補完以外に、 DirectorySeparatorCharを使用するオプションが必要な場所で、 AltDirectorySeparatorCharが使用されていないと感じる場所はありますか？ 何も思いつかない。

@KirkMunro 、今日PowerShellでパスを正規化する（少なくとも部分的に実装された）方法があると言っていますか？ もしそうなら、それは最新の6.xで動作しますか？ 私が問題を抱えていたユースケースは、自動変数と*-Pathコマンドでした。

@iSazonov 、提案されたソリューションは、Windowsでパスのリストを生成し、Linuxでパスのリストを生成し、それらを比較しようとしたため、私のシナリオでは機能しませんでしたが、セパレーターが原因で失敗しました。

自動変数には常に末尾のディレクトリ区切り文字がないため、PowerShellではリテラルを使用してパスを美しく作成できます。 元：

$RepoRoot = "$PSScriptRoot/../.."
$SourceRoot = "$RepoRoot/src"
$BuildRoot = "$RepoRoot/.build"

これはより明確だと思います

$RepoRoot = Join-Path $PSScriptRoot "../.."
$SourceRoot = Join-Path $RepoRoot "src"
$BuildRoot = Join-Path $RepoRoot ".build"

ですから、デフォルトでなくても、将来的には機能することを願っています。

@chriskuech私の個人的な習慣は次のようになりました：

$SourceRoot = $RepoRoot | Join-Path -ChildPath 'src'

少しわかりやすくなっていますが、完璧ではありません。

Join-Pathには、文字列配列を受け入れるAdditionalChildPathがあります。

@chriskuech追加情報をありがとう。

PowerShellがパスの正規化を部分的にサポートしていることを示唆していませんでした。 私は、タブ補完がWindowsではデフォルトでバックスラッシュを使用し、LinuxまたはmacOSではデフォルトでスラッシュを使用することを個人的に嫌っていることを単に呼びかけていました。

設定を微調整して、デフォルトでWindowsパスでもスラッシュが使用されるように変更できれば、その変更を行うことになります。これは、クロスプラットフォームのPowerShellをより簡単に機能させる機会があると思う場所の1つです。 Join-Pathは、パス区切り文字として[System.IO.Path]::DirectorySeparatorCharも使用します。 理想的には、スクリプトを作成するときに目的のパス区切り文字を設定する設定がある場合（スクリプトを作成するプラットフォームに関係なく、希望する方法でスクリプトを簡単に作成できるはずなので）、両方のタブ補完に反映されます。パスとJoin-Pathも同様です。

これらの個人的なニーズはさておき、 Compare-Pathコマンドレットが役立つかどうか疑問に思います。 パスセパレータを正規化し、パスの1つが絶対パスである場合は、比較が行われる前に相対パスを解決することにより、絶対パスを相対パスと比較することもできます。

ええと、 Convert-PathとResolve-Pathで_プラットフォーム固有の_正規化を取得します：

PS> Convert-Path C:/Windows
C:\Windows # normalized to Windows-native "\"

したがって、おそらくCompare-Pathコマンドレットを導入する代わりに、 Convert-PathとResolve-Pathを拡張して-UseSlashスイッチ（名前は交渉可能）をサポートすることができます。

これとは別に、補完的に、Kirkが提案するWindowsで/を使用するためのオプトイン設定メカニズムは、 Convert-PathとResolve-Pathにも適用できます（タブ補完とJoin-Pathに加えて）

現時点での落とし穴は、 Convert-PathとResolve-Pathは_existing_パスでのみ機能するということですが、 @ jaykulがかなり前に提案したように、それ自体で変更する価値があります-＃2993を参照してください

パス補完で、補完テキストに明示的に表示されるパス区切り文字を使用すると便利だと思います。パス区切り文字がない場合は、デフォルトでプラットフォームのネイティブ区切り文字になります。

したがって、Windowsでは、 c:\wはc:\Windows\ $に完了し、 c:/wは 'c：/ Windows /'に完了します。

これは、構成オプションを必要とせずに煩わしさの大部分をカバーすると思います。何らかの理由で他のフォームが必要になる場合があるため、実際には望ましい方法です。

@lzybkr 、私が言及しなかった構成/設定変数ベースのソリューションに関する懸念に照らして、私はこのアイデアが好きです。 通常の_dynamic_スコープでは、パスセパレーターについて固定された仮定を行うコードが壊れることがあります（https://github.com/PowerShell/PowerShell-RFC/issues/7のエコーがあります）。

@lzybkrと両方のスラッシュが使用されている場合は？ C:\Program Files/A ->？

非常に多くのオプション-ランダム、それぞれを交互に、常にスラッシュb / cを転送し、それが1つの真のパス区切り文字などです。

もっと真剣に言うと、最後に使用したものを選択するだけです。おそらくユーザーが入力したものですが、他の人は入力しない場合があります。

@lzybkr ：ただし、1つの問題があります。

パス区切り文字なしで起動した場合、現在のディレクトリ内のファイル/フォルダーを参照するために、PowerShellは、少なくとも.\<filename>または./<filename>に展開される現在の完了アルゴリズムに基づいて選択を行う必要があります。 .\<folder>\または./<folder>/ 、プラットフォームに適しています。

_files_ as _arguments_の場合、たとえば、 filをfileに拡張することで、この問題を回避できます（ .\ / ./プレフィックスなし）。

でも：

• _executables_の場合、自動的に追加された.\ / ./プレフィックスは、現在のディレクトリにあるスクリプトを実際に実行することを目的としている場合に非常に便利です。

• _directories_の場合も同様に、_末尾のパス区切り文字_（ <folder>\または<folder>/ ）を使用して拡張することも重要です。

どちらの場合も、優先セパレーターを暗示するユーザーアクションはありません。

とはいえ、おそらく解決策は次のとおりです。セパレータを制御する場合は、_手動で_ ./または.\から開始し、タブ補完でそれを尊重します。

この問題は回答済みとしてマークされており、 1日間アクティビティがありません。 ハウスキーピングのため閉鎖されています。

@iSazonov ：これは実際には答えられていないので、進行中の議論がこれを解決し続けることができるように再開する必要があります。 OPには、彼に返される質問に答える機会すらありませんでした。

私はすべての質問に答えたと思いますが、答えなかった場合は知らせてください。 私もこの問題が解決された理由がわかりません。 これはディスカッションスレッドとしてではなく、機能のリクエストとして意図されていました。

手元にある根本的な問題：

• クロスプラットフォームツールは、デフォルトで非クロスプラットフォームの動作をする必要がありますか？
• もしそうなら、PowerShellを「クロスプラットフォーム」モードでグローバルに実行する方法があるべきですか？

開発者にコマンドレットを使用して文字列を手動で正規化するように強制することは、間違いなく間違った動きだと思います。 前述のように、PowerShellは両方の種類のスラッシュの処理に非常に優れているため、デフォルト/を使用するとWindowsで問題が発生するシナリオはありません。 これがエラーを引き起こすような説得力のある状況を誰かが提供できない限り、デフォルト/を使用しないのはなぜですか？ おそらく、この問題はRFCに移行する必要があります。

より多くの人々がクラウドに移行するにつれて、ますます多くの人々がWindowsでPowerShellコードを開発し、それをLinuxで実行します。 確かに将来的には（まだ通過していない場合）、真のクロスプラットフォーム動作を好むユーザーの数が、Windowsで\を維持することを強く望んでいるユーザーを超えるポイントがあります。

@chriskuech ：悪いことに、私はあなたに具体的に質問をしませんでした。 Conpare-Pathコマンドレットが役立つと感じたかどうか疑問に思いました。 その質問はさておき、正規化オプションも見たいと思います。

@KirkMunro Compare-Pathが役立つかどうかはわかりません。これは、元のユースケース（LinuxとWindowsのパスを比較）ではルートファイルシステムが異なるため、 Resolve-Path -Relativeを呼び出す必要があるためです。 その時点で、比較のユースケースは単なるワンライナーです： | ? {($_ -replace "\\", "/") -in $ExpectedPaths} 。

ただし、コマンドレットベースのソリューションは根本的な問題を解決せず、パスの文字列補間を禁止するか、すべてのパス文字列定義にコードを変更する必要があるため、私はコマンドレットベースのソリューションを推奨することを非常に躊躇しています。 具体的には、 Compare-Pathは、ログに記録されたすべてのパスをスラッシュが混在して修正するわけではありません。

@KirkMunro @ mklement0問題はロックされておらず、誰でもコメントを引き出すことができます。
新しいコメントや進展がないまま、多くの問題があります。 オープンステータスはその意味を失いました。
メンテナとして、PRになりやすいより厳密な仕様に議論を促すために、より厳密にしたいと思います。
問題に関しては、それは無限になります-最初の要求は「Windowsでスラッシュを使用する」、次に「パスを比較する」でした。 次は何ですか？ リモーティング？ 継続することはできますが、閉鎖されます。
ジェイソンからの実際の提案は1つだけでしたが（完了を強化するため）、追跡の問題を開いて実際のPRで閉じることができました。

明確にするために、問題はまだ「Windowsでスラッシュを使用する」ことです。 「パスの比較」は、（複数の）動機付けの例の1つとしてのみ取り上げられました。

提案
真のクロスプラットフォーム動作を実装します。ユーザーがすでに\を含むパスをタブで完了していない限り、パス区切り文字はすべてのプラットフォームでデフォルトで/になります。 これは今のところ実験的な機能として隠されていると思いますが、少なくともLinuxをターゲットとするWindows開発者の開発エクスペリエンスを最適化するために、コードで「クロスプラットフォームの動作を最大化する」機能を有効にできるはずです。

これが不合理な場合は、PowerShellの設計がプラットフォーム間で異なる場合の理由とガイドとなるドキュメントがあるかどうかを知りたいと思います。

@iSazonov ：PSリポジトリのメンテナは、議論なしにユーザーの問題を否定するべきではありません。 当初、OPのニーズを理解するために時間をかけずに返信し、問題を回答済みとしてマークしましたが、問題は質問として投稿されておらず、機能リクエストとして投稿されており、ディスカッションからわかるように、明確に示されています。答えなかった"。

オープンステータスはその意味を失いました。

誰が言いますか？ それは絶対に真実ではありません。 未解決の問題は未解決であり、未解決の問題は解決されています。 これらの2つの違いは非常に明確な意味を持っています。 クローズされた問題は自分のものである場合にのみ確認し、戻って何かを確認したいと思います。 まれに、特定のトピックに関するディスカッションのために、クローズされた問題を検索する場合があります。 しかし、私の問題に費やす時間の90％以上は、当然のことながら未解決の問題にあります。 2つの間の境界線を曖昧にし、未解決の問題の意味を失う唯一のことは、この問題で行ったように、解決される前にそれらをまとめて閉じることです。

（議論）は継続するために開かれていますが、閉じられます。

問題を管理するこのアプローチに基づいて、オープンとクローズの区別を失うことを余儀なくされているため、オープンの問題に焦点を合わせるのではなく、すべての問題を検索する必要があります。つまり、2Kのオープンの問題と4Kのクローズの問題をチェックする必要があります。未解決の問題だけに焦点を当てるのではなく、それらに関連する議論のために。 それは壊れた、欠陥のある問題管理戦略です。

問題に関しては、それは無限になります-最初の要求は「Windowsでスラッシュを使用する」、次に「パスを比較する」でした。 次は何ですか？ リモーティング？

それはばかげています。 クロスプラットフォーム用のスクリプトを作成するときに、デフォルトとしてバックスラッシュを持つWindowsの処理に焦点を当てています。 それはそのトピックに焦点を合わせ続けています。 まったく焦点が合っていないように聞こえるようにしようとしています。

@iSazonov 、未解決の問題が多すぎることに同意します。 ただし、未解決の問題が多すぎるという事実は、新しい問題についての会話を時期尚早に否定し、シャットダウンする必要があることを意味するものではありません。 引き続きフィードバックを奨励し、未解決の問題についてPowerShellについてオープンに話し合い、真に解決された場合にのみ終了する必要があります。 未解決の問題の量は、別の方法で処理する必要があります。

忠実なLinuxユーザー？理解できないアドバイス。
あなたはマイクロソフトを説得することができます。 システムファイルパスとしてバックスラッシュを使用するように依頼します。

ここでチャイムを鳴らしたいのですが、Windowsでも、スラッシュ付きのリテラルパスが必要なユースケースがあります。

.netAPIを使用してzipアーカイブを操作および作成するスクリプトを書いていました。 このAPIを使用してzipファイルにエントリを追加します。

    [System.IO.Compression.ZipFileExtensions]::CreateEntryFromFile(
        $zip, $file, $entry,
        [System.IO.Compression.CompressionLevel]::Optimal
    ) > $null

この特定のケースでは、$ entryはzipアーカイブ内のパスです。 さまざまなパスコマンドレットによって返されるWindowsパスを渡すだけでは、地球上のすべてのzipユーティリティが、zipファイルのスラッシュが間違っているという警告を発します。

また、長年のLinuxユーザーおよび開発者として、私はPowerShellが大好きで、それを学ぶのがとても楽しいです。 sshを介して新しいWindowsServerコアをPowerShell7で遊んで楽しんでいます。また、Linux上のPowerShellで完全に機能するスクリプトを公開しています。 私はそれがどれほどうまく機能するかに驚いた。 実際、クロスプラットフォームにしたいいくつかのプログラム/スクリプトでは、PowerShellが最初の選択肢になります。

ただし、タブの補完がすべて円記号で書き直されるのを見ると、それでも悲しくなります。

私はいつもWindowsで/ users / foo / somefileのようなパスを使用しており、それを使用したいと思っています。

ほとんどのWindowsAPIは、スラッシュを適切にサポートしています。 ユーティリティやAPI、つまりcmd.exeの呼び出しなど、いくつかの例外があることに気付きましたが、バックスラッシュを明示的に使用していない限り、デフォルトですべてのパスにスラッシュが含まれるように、$ profileに何かを設定したいと思います。

これは、バックスラッシュに慣れているWindowsユーザーや開発者にとっては不快ではありません。これは、単にこの設定を使用せず、デフォルトでオフになるためです。 もちろん、たとえばクロスプラットフォームのスクリプトやモジュールをさらに作成することにした場合は、それを使用することもできます。

上記のような予期しない問題が発生しないように、スクリプトとモジュールにもこの設定が必要です。

@iSazonovユーザーは、プラットフォームに関係なく快適なスラッシュを使用できます。

これは、ユーザーとしての方が快適なので、スラッシュを使用するようにPowerShellを構成できることを意味しますか？ プロンプトに表示されるパスと、現在スラッシュをバックスラッシュに変更しているタブのオートコンプリートを変更したいと思います。

@aaronfranke 、いいえ、現在、PowerShellをこのように構成する方法はありません。 @iSazonovが言おうとしていたのは、パスを手動で入力する場合、 \と/のどちらかを自由に選択できるということだと思います（単一のパスにそれらを混在させることもできます） 。

汎用性を考慮すると、/およびの代わりに新しいパスシンボルを有効にする必要があります。従来のシンボルは、プラットフォーム間での変換の難しさを増します。

@iSazonovが言おうとしていたのは、パスを手動で入力するときは、と/のどちらかを自由に選択できるということだと思います（1つのパスにそれらを混在させることもできます）。

はい、PowerShellの設計です。

これは、完了時にパスセパレータを強制的に交換したり、選択したパスセパレータを使用するようにパスコマンドレットを構成したりするなど、ここで提起された問題の解決策ではありません。 ？

@rkitover私は何年も前にそのようなシナリオについて尋ねました（あなたは問題を見つけることができます）解決策はありません。 これは、多くの労力を必要としますが、これは見た目の変更であると私に確信させます。 この分野に投資してPRを行う準備ができている場合は、新しいディスカッションを開くのが理にかなっています。

CP / Mとクローンは、オプションに/を使用します。例： DIR/P 、 CMD/CECHO 。 これらは有効なコマンドです。 どこでも\を/に置き換えると、悪い誤解が生じるのではないかと心配しています。

1. 誰もCP / Mをもう使用していません。

2. オプションとパスの両方に同時に/を使用することは、私のテストではWindowsで問題なく機能します。

3. PowerShellツールや.NETなどの他のMicrosoftツールなど、最新のツールは代わりにオプションに-を使用します。 オプションに/を使用することは、下位互換性のために維持する必要がありますが、ユーザーは最新のツールと混同することはありません。

また、スラッシュ/は、Win32ファイル名では無効な文字名であることに注意してください。

https://gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3

要旨

Windowsファイル名の無効な文字

Windowsファイル名の文字が無効です。 GitHub Gist：コード、メモ、スニペットを即座に共有します。

クロスプラットフォームスクリプトなどでのみスラッシュを使用し始め、シンボリックリンクで問題が発生したことを指摘したいと思います。

例として、

new-item -itemtype SymbolicLink -path TestScript8.ps1 -target ./TestScript.ps1

Windowsでは、WindowsのVSCodeでTestScript8.ps1を開くことはできません。

@ markm77 、あなたは_bug_を発見しました-新しい問題を作成していただけますか？ [_update _：＃13064を参照]

デフォルトで/ 、 @ aaronfrankeに設定するためのオプトインメカニズムに反対する議論ではありませんが、 \ / ＃$がまだ壊れているエッジケースはほとんどないことに注意してくださいWindows上のもの; 例えば：

PS> cmd /c dir C:/
Invalid switch - ""

パスを二重引用符で囲むと、不思議なことに_directory_パスでのみ役立ちます。https： //stackoverflow.com/a/43297482/45375を参照してください。これは、Excel COM Automationライブラリが/をサポートしていないことも示しています。

スタックオーバーフロー

PowerShellがファイルをCSVとして保存したくないのはなぜですか

$ Path = 'D：/ETL_Data/TwitchTVData.xlsx' $ csvPath = 'D：/ETL_Data/TwitchTVData2.csv'＃Excelドキュメントを開き、' Sheet1 'ワークシートをプルします$ Excel = New-Object -Com Excel.Application $ Workbook..。

@ markm77 、バグを発見しました-新しい問題を作成していただけますか？

しかし、これはPowerShellのバグですか？ PowerShellは、 dirを使用してシンボリックリンクを調べることで検証されたように、指定されたスラッシュで正しいシンボリックリンクを作成します。 ただし、間違ったスラッシュタイプで作成されたシンボリックリンクは、VSCodeなどのアプリでは使用できなくなる可能性があります。 これもおそらく理解できます。

注意：シンボリックリンクターゲットでconvert-itemを実行することで、この問題を回避するのは非常に簡単です。これには、シンボリックリンクが絶対パスを指すようにするという追加の利点があります（おそらく適切です）。

注意：シンボリックリンクターゲットでconvert-itemを実行することで、この問題を回避するのは非常に簡単です。これには、シンボリックリンクが絶対パスを指すようにするという追加の利点があります（おそらく適切です）。

不適切、再マウント時に破損します😞

不適切、再マウント時に破損します😞

公正なコメントです。再マウントはしません（これはローカル開発作業用です）。リンクを再生成するためのスクリプトがあり、いつでも実行できます。 join-pathは明らかに他の解決策であり、リンクがプラットフォームに適していることを確認するためのnew-itemオプションの方がさらに良いでしょう。

＃12797を参照

しかし、これはPowerShellのバグですか？

_Windows_ではWinAPIのバグであると主張することもできますが、 \と/は通常互換的にサポートされているため、逆にしてパスすると、Unixライクなプラットフォームでは間違いなくバグになります。 -Target \ベースのパス-このようなプラットフォームでは、 /のみがネイティブにサポートされます（ \を次のように使用できるのはPowerShellのみです独自の問題を伴う代替手段-＃9244を参照）。シンボリックリンクを作成するときに.\TestScript.ps1のようなものを./TestScript.ps1に変換するのはPowerShellの責任です。

これを修正すると（PowerShellでパスを正規化して（プライマリ）_platform-native_セパレーターを使用するようにすることで）、Windowsでの問題も修正されます。

@ iSazonov 、＃12797は、シンボリックリンクターゲットとしての_relative_パスのサポートを基本的に有効にしましたが、当面の問題は、プラットフォームネイティブのセパレーターの正規化がないため、結果のシンボリックリンクが壊れてしまうことです。

@iSazonov PowerShell Core 7.1.0-preview.4（これには＃12797が含まれているはずです）の時点でまだ壊れているものについては、＃13064を参照してください。

相対的なシンボリックリンクの動作を徹底的に調査し、問題を提起してくれた@ mklement0に感謝しますhttps://github.com/PowerShell/PowerShell/issues/13064。 私が抱えていた特定の問題とこの議論をさらにフォローアップするためにメモを取りましたが、実際にはhttps://github.com/PowerShell/PowerShell/issues/13064ですべてをカバーしているようで、実際にその方法を教えてくれましたPowerShellテストを作成する（PowerShellは初めてです）...乾杯！

私はこの問題を詳細にフォローしていなかったので、何かが足りない場合はすみません。 最初の問題は、クロスプラットフォームの標準化されたパス区切り文字（場合によってはスラッシュ）でした。 @iSazonovはこの問題を解決しました。 問題のクローズイベントに登録した人々がフォローできるように、これがもはや有効でないと思う理由の概要を教えてください。

https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471によると、これは決して有効ではありませんでした。

@lzybkrが上で提案したようなものは、まだ完全に合理的であり、おそらく簡単に実装できます。 要点をまとめると：

パス補完で、補完テキストに明示的に表示されるパス区切り文字を使用すると便利だと思います。パス区切り文字がない場合は、デフォルトでプラットフォームのネイティブ区切り文字になります。

その場合、Windowsで/がまだ壊れている-まれな-エッジケースを回避するのはユーザーの責任です（上記を参照）。

これは、PowerShellを介してwslbashスクリプトを実行するときに深刻な問題を引き起こします。 好き：

bash .\updateTemplate.sh

これはオートコンプリートする必要があります

bash ./updateTemplate.sh

この問題に対する他の回避策はありますか？ 具体的には、PSがbash / WSLコンテキストでのみスラッシュを使用してパスをオートコンプリートできれば、まったく問題ありません。

この問題に対する他の回避策はありますか？

bashのカスタムコンプリーターを作成します。

この問題に対する他の回避策はありますか？

bashのカスタムコンプリーターを作成します。

これはどうやるんですか？

この問題の根拠のない閉鎖について、これ以上の議論はありませんか？ これは、クロスプラットフォーム作業の大きな問題です。 クロスプラットフォームツールにフィードされるパス、またはwslを介してLinuxツールに間接的にフィードされるパスを自動完了するたびに、パス全体でカーソルを逆方向​​に移動し、すべてのバックスラッシュをスラッシュに個別に置き換える必要があります。 誰もこのように作業する必要はありません。これにより、コマンドラインとしてのPowershellはほとんど使用できなくなります。