현재 대안은 사용자가 경로를 정규화하도록 하는 것입니다.

PowerShell은 이미 작업을 수행하므로 경로를 정규화할 필요가 없습니다.
PowerShell은 여기에서 매우 사용자 친화적입니다. 사용자는 플랫폼에 관계없이 편안한 슬래시를 사용할 수 있습니다.
모범 사례는 리터럴 경로를 사용하지 않고 경로 cmdlet을 사용하는 것입니다.

모범 사례는 리터럴 경로를 사용하지 않고 경로 cmdlet을 사용하는 것입니다.

@iSazonov 예 및 아니오.

물론, 경로 세그먼트를 결합하는 경우 경로 cmdlet을 사용할 수 있습니다. 그러나 여러 세그먼트가 있는 상대 경로를 참조하는 스크립트를 작성하고 스크립트가 플랫폼 간에 작동하도록 하려는 경우에는 그렇게 하지 않을 것입니다.

Windows의 PowerShell 7 미리 보기 3에서 탭 완성은 백슬래시를 사용하여 경로를 완성합니다. 그것이 바로 PowerShell이 ​​크로스 플랫폼이기 때문에 우리가 잘못하고 있다고 생각하는 한 곳입니다. 탭 완성의 일부로 Windows에서 사용하려는 디렉토리 구분 문자를 선택하는 옵션이 최소한 있어야 합니다: [System.IO.Path]::DirectorySeparatorChar 또는 [System.IO.Path]::AltDirectorySeparatorChar . 현재 우리가 어디에 있는지 감안할 때 크로스 플랫폼 작업을 수행하는 대부분의 사람들은 기본적으로 Windows에서 AltDirectorySeparatorChar 를 사용하기 위해 경로의 탭 완성을 원할 것이라고 생각하지만, 내가 아는 한 그렇게 할 수 있는 방법은 없습니다. .

@chriskuech : 경로의 탭 완성 외에도 DirectorySeparatorChar 대신 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을 더 쉽게 작동할 수 있는 기회가 있을 수 있다고 생각합니다. Join-Path 는 경로 구분자로 [System.IO.Path]::DirectorySeparatorChar 도 사용합니다. 이상적으로는 스크립트를 작성할 때 원하는 경로 구분자를 설정하는 설정이 있는 경우(왜냐하면 스크립트를 작성하기로 선택한 플랫폼에 관계없이 원하는 방식으로 스크립트를 쉽게 작성할 수 있어야 하기 때문입니다), 두 탭 완성에 반영됩니다. 경로 및 Join-Path 도 있습니다.

이러한 개인적인 요구는 제쳐두고 Compare-Path cmdlet이 유용할지 궁금합니다. 경로 구분자를 정규화하고 경로 중 하나가 절대 경로인 경우 비교가 수행되기 전에 상대 경로를 확인하여 절대 경로를 상대 경로와 비교할 수도 있습니다.

글쎄, 우리는 Convert-Path 및 Resolve-Path 에서 _플랫폼별_ 정규화를 얻습니다.

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

따라서 Compare-Path cmdlet을 도입하는 대신 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는 하나의 진정한 경로 구분 기호 등입니다.

더 진지하게, 아마도 사용자가 입력한 마지막 항목을 선택하고 다른 항목은 입력하지 않을 수 있습니다.

@lzybkr : 하지만 한 가지 문제가 있습니다.

경로 구분 기호 없이_ 시작하는 경우 _현재 디렉터리_에 있는 파일/폴더를 참조하기 위해 PowerShell은 최소한 .\<filename> 또는 ./<filename> 로 확장되는 현재 완료 알고리즘을 기반으로 선택해야 합니다. .\<folder>\ 또는 ./<folder>/ , 플랫폼에 적합합니다.

_files_의 경우 _arguments_의 경우 fil 를 file 로 확장하여 해당 문제를 피할 수 있습니다( .\ / ./ 접두사 없음).

하지만:

• _executables_ 의 경우 자동으로 추가된 .\ / ./ 접두사는 실제로 현재 디렉터리에 있는 스크립트를 실행하려는 의도인 경우 유용한 편리함입니다.

• _directories_의 경우와 유사하게 _trailing path separator_ ( <folder>\ 또는 <folder>/ )로 확장하는 것도 가치가 있습니다.

두 경우 모두 선호하는 구분 기호를 암시하는 사용자 작업이 없습니다.

즉, 아마도 해결책은 다음과 같습니다. 구분 기호를 제어하려면 ./ 또는 .\ 로 _수동으로 시작하고 탭 완성이 이를 준수하도록 합니다.

이 문제는 답변된 것으로 표시되었으며 1일 동안 활동이 없습니다. 하우스키핑을 위해 폐쇄되었습니다.

@iSazonov : 이것은 실제로 답변되지 않았으며 진행 중인 토론에서 이 문제를 계속 해결할 수 있도록 다시 열어야 합니다. OP는 그에게 다시 묻는 질문에 대답할 기회조차 없었습니다.

나는 모든 질문을 나에게 다뤘다고 생각하지만 그렇지 않은 경우 알려주십시오. 이 문제가 왜 닫혔는지 나도 잘 모르겠습니다. 토론 스레드가 아니라 기능 요청이었습니다.

당면한 근본 문제:

• 플랫폼 간 도구에 기본적으로 비 교차 플랫폼 동작이 있어야 합니까?
• 그렇다면 "교차 플랫폼" 모드에서 PowerShell을 전역적으로 실행할 수 있는 방법이 있어야 합니까?

개발자가 cmdlet을 사용하여 문자열을 수동으로 정규화하도록 강요하는 것은 확실히 잘못된 행동이라고 생각합니다. 기본적으로 / 를 사용하면 Windows에서 문제가 발생하는 시나리오가 보이지 않습니다. 앞에서 언급한 것처럼 PowerShell은 두 종류의 슬래시를 모두 처리하는 데 매우 유용하기 때문입니다. 이것이 오류를 일으킬 수 있는 강력한 상황을 제공할 수 있는 사람이 없는 한 기본적으로 / 를 사용하지 않는 이유는 무엇입니까? 아마도 이 문제는 RFC로 옮겨야 합니다.

더 많은 사람들이 클라우드로 마이그레이션하면서 더 많은 사람들이 Windows에서 PowerShell 코드를 개발하고 Linux에서 실행합니다. 미래에는 (아직 통과되지 않은 경우) 진정한 크로스 플랫폼 동작을 선호하는 사용자의 수가 Windows에서 \ 를 유지하는 것에 대해 강하게 느끼는 모든 사용자를 능가하는 시점이 분명히 있을 것입니다.

@chriskuech : 죄송합니다. 특별히 질문을 드린 것은 아닙니다. Conpare-Path cmdlet이 도움이 될 것이라고 생각하는지 궁금합니다. 그 질문은 제쳐두고 정규화 옵션도 보고 싶습니다.

@KirkMunro Compare-Path 이 도움이 될지 잘 모르겠습니다. 원래 사용 사례(Linux 및 Windows의 경로 비교)에서 루트 파일 시스템이 다르기 때문에 Resolve-Path -Relative 를 호출해야 하기 때문입니다. 그 시점에서 비교 사용 사례는 | ? {($_ -replace "\\", "/") -in $ExpectedPaths} 한 줄짜리입니다.

그러나 cmdlet 기반 솔루션은 근본 문제를 해결하지 못하고 경로에 대한 문자열 보간을 허용하지 않거나 모든 경로 문자열 정의에 대한 코드 변경을 요구하므로 승인하는 것을 매우 주저합니다. 특히 Compare-Path 는 기록된 모든 경로를 슬래시가 혼합된 상태로 수정하지 않습니다.

@KirkMunro @mklement0 문제는 잠겨 있지 않으며 모든 사람이 댓글을 가져올 수 있습니다.
새로운 의견과 진행 상황이 없는 문제가 많습니다. 열린 상태는 의미를 잃었습니다.
메인테이너로서, 나는 토론이 PR로 쉽게 바뀔 수 있는 보다 엄격한 사양이 되도록 장려하기 위해 보다 엄격하게 할 생각입니다.
문제에 관해서는 무한으로 바뀝니다. 초기 요청은 "Windows에서 슬래시 사용", "경로 비교"였습니다. 다음은 뭐야? 원격? 계속하기 위해 열려 있지만 닫힐 것입니다.
Jason의 실제 제안은 단 하나(완성 향상을 위해) 위에 있었고 추적 문제를 열고 실제 PR로 닫을 수 있었습니다.

분명히 하기 위해 문제는 여전히 "Windows에서 슬래시 사용"입니다. "경로 비교"는 (여러 개 중) 동기를 부여하는 예로만 언급되었습니다.

제안
사용자가 이미 \ 가 포함된 경로를 탭 완성하지 않는 한 모든 플랫폼에서 경로 구분 기호가 기본적으로 / 인 진정한 플랫폼 간 동작을 구현합니다. 현재로서는 이것이 실험적 기능으로 숨겨져 있을 것으로 예상되지만 Linux를 대상으로 하는 Windows 개발자의 개발 경험을 최적화하기 위해 내 코드에서 "플랫폼 간 동작 최대화" 기능을 활성화할 수 있어야 합니다.

이것이 불합리한 경우 PowerShell 디자인이 플랫폼 간에 분기되는 경우를 안내하는 문서가 있는 이유와 이유를 알고 싶습니다.

@iSazonov : PS 저장소의 관리자는 토론 없이 사용자 문제를 무시해서는 안 됩니다. 귀하는 원래 OP의 요구 사항을 이해하는 데 시간을 들이지 않고 문제를 답변됨으로 표시하여 답변했지만 문제는 질문으로 게시되지 않았고 기능 요청으로 게시되었으며 토론에서 볼 수 있듯이 명확합니다. "답변"이 아닙니다.

열린 상태는 의미를 잃었습니다.

누가 말합니까? 그것은 사실이 아닙니다. 미해결 문제가 열려 있고 닫힌 문제가 닫혀 있습니다. 이 두 가지 구분은 매우 분명한 의미를 갖습니다. 닫힌 문제가 내 문제인 경우에만 확인하고 다시 돌아가서 확인하고 싶은 문제가 있습니다. 드문 경우지만 특정 주제에 대한 토론을 위해 비공개 문제를 검색할 수 있습니다. 그러나 문제에 대한 내 시간의 90% 이상은 당연히 그래야 하는 미결 문제에 있습니다. 둘 사이의 경계를 흐리게 하고 미해결 문제의 의미를 잃게 만드는 유일한 방법은 이 문제에서 했던 것처럼 해결되기 전에 간단히 닫는 것입니다.

(토론) 계속하기 위해 열려 있지만 닫힐 것입니다.

이러한 문제 관리 접근 방식을 기반으로 하면 사람들이 공개 문제와 비공개 문제의 구분을 잃게 되므로 공개 문제에 집중하기보다 모든 문제를 검색해야 합니다. 즉, 2K 공개 문제와 4K 비공개 문제를 확인해야 합니다. 미해결 문제에만 초점을 맞추는 대신 그들과 관련된 토론을 위해. 그것은 부서지고 결함이 있는 문제 관리 전략입니다.

문제에 관해서는 무한으로 바뀝니다. 초기 요청은 "Windows에서 슬래시 사용", "경로 비교"였습니다. 다음은 뭐야? 원격?

그건 말도 안돼. 논의는 크로스 플랫폼용 스크립트를 작성할 때 백슬래시를 기본값으로 사용하는 Windows를 처리하는 데 중점을 둡니다. 그 주제에 계속 초점을 맞췄습니다. 초점이 전혀 맞지 않는 것처럼 들리도록 하려고 합니다.

@iSazonov , 너무 많은 미해결 문제가 있다는 데 동의합니다. 그러나 미해결 문제가 너무 많다는 사실이 우리가 새로운 문제에 대해 무시하고 조기에 대화를 종료해야 한다는 것을 의미하지는 않습니다. 우리는 계속해서 피드백을 장려하고 미해결 문제에서 PowerShell에 대한 토론을 열어야 하며, 진정으로 해결된 후에만 종료해야 합니다. 미해결 문제의 양은 다르게 다루어야 합니다.

충성스러운 Linux 사용자?이해할 수 없는 조언.
마이크로소프트를 설득할 수 있습니다. 시스템 파일 경로로 백슬래시를 사용하도록 요청하십시오.

Windows에서도 슬래시가 있는 리터럴 경로가 필요한 사용 사례가 있다는 점을 알려드리고 싶습니다.

저는 .net API를 사용하여 zip 아카이브를 조작하고 생성하는 스크립트를 작성하고 있었습니다. 이 API를 사용하여 zip 파일에 항목 추가:

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

이 특별한 경우 $entry는 zip 아카이브 내의 경로입니다. 다양한 경로 cmdlet에서 반환된 대로 Windows 경로를 전달하기만 하면 지구상의 모든 zip 유틸리티에서 내 zip 파일에 잘못된 슬래시가 있다는 경고를 표시합니다.

또한 오랜 시간 Linux 사용자이자 개발자로서 저는 powershell을 사랑하고 그것을 배우는 데 많은 재미를 느끼고 있습니다. 나는 ssh를 통해 powershell 7로도 새로운 Windows 서버 코어를 가지고 재미있게 놀고 있으며 Linux의 powershell과 완벽하게 작동하는 스크립트를 게시했습니다. 나는 그것이 얼마나 잘 작동하는지 놀랐다. 사실, powershell은 내가 크로스 플랫폼을 원하는 일부 프로그램/스크립트에 대한 첫 번째 선택이 될 것입니다.

그러나 내 모든 탭 완성이 백슬래시로 다시 작성되는 것을 보니 여전히 안타깝습니다.

나는 Windows에서 항상 /users/foo/somefile과 같은 경로를 사용하며 이것이 내가 사용하고 싶은 것입니다.

대부분의 Windows API는 슬래시를 잘 지원합니다. 유틸리티 및 API, 즉 일부 cmd.exe 호출에 몇 가지 예외가 있다는 것을 알고 있지만 백슬래시를 명시적으로 사용하지 않는 한 기본적으로 모든 경로에 슬래시가 있도록 $profile에 무언가를 설정하고 싶습니다.

백슬래시를 사용하는 Windows 사용자와 개발자는 이 설정을 사용하지 않고 기본적으로 꺼짐으로 설정되어 있기 때문에 이는 불쾌감을 주지 않습니다. 물론 예를 들어 크로스 플랫폼 스크립트와 모듈을 더 많이 작성하기로 결정한 경우에도 사용하기로 결정할 수 있습니다.

내 스크립트와 모듈에도 이 설정을 사용하여 위에서 보여드린 것과 같은 예기치 않은 문제가 발생하지 않도록 하고 싶습니다.

@iSazonov 사용자는 플랫폼에 관계없이 편안한 슬래시를 사용할 수 있습니다.

슬래시를 사용하는 것이 사용자에게 더 편하기 때문에 PowerShell을 구성하여 슬래시를 사용할 수 있다는 의미입니까? 프롬프트에 표시된 경로와 현재 슬래시를 백슬래시로 변경하는 탭 자동 완성을 변경하고 싶습니다.

@aaronfranke , 아니요, 현재 이 방식으로 PowerShell을 구성할 방법이 없습니다. @iSazonov 가 말하려고 했던 것은 경로를 수동으로 입력할 때 \ 와 / 중에서 자유롭게 선택할 수 있다는 것입니다(또한 단일 경로에 혼합할 수도 있음) .

다양성을 고려하여 / 대신 새 경로 기호를 활성화해야 합니다. ，전통적인 기호는 플랫폼 간 변환의 어려움을 높입니다.

@iSazonov 가 말하려고 했던 것은 수동으로 경로를 입력할 때 및 / 중에서 자유롭게 선택할 수 있다는 것입니다(또한 단일 경로에서 혼합할 수도 있습니다).

예, PowerShell 디자인입니다.

이것은 완료 중 경로 구분 기호의 강제 교체 또는 선택한 경로 구분 기호를 사용하도록 경로 cmdlet을 구성하는 기능과 같이 여기에서 제기된 문제의 해결 방법이 아닙니다. ?

@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의 VS Code에서 TestScript8.ps1을 열 수 없습니다.

@markm77 , _bug_를 발견했습니다 . 새 문제를 만들어 주시겠습니까? [_update_: #13064 참조]

기본값을 / , @aaronfranke 로 설정하는 옵트인 메커니즘에 대한 논쟁은 아니지만 $#$2 / 대신 \ 가 여전히 중단되는 경우는 거의 없습니다. Windows의 것들; 예:

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

경로를 큰따옴표로 묶는 것은 _directory_ 경로에만 도움이 됩니다. 흥미롭게도 https://stackoverflow.com/a/43297482/45375 를 참조하십시오. Excel COM 자동화 라이브러리가 / 를 지원하지 않는다는 것도 보여줍니다.

스택 오버플로

PowerShell이 ​​내 파일을 CSV로 저장하지 않으려는 이유

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Excel 문서를 열고 'Sheet1' 워크시트를 가져옵니다. $Excel = New-Object -Com Excel.Application $워크북...

@markm77 , 버그를 발견했습니다. 새 문제를 만들어 주시겠습니까?

그러나 이것이 PowerShell 버그입니까? PowerShell은 dir 를 사용하여 심볼릭 링크를 검사하여 확인된 대로 지정된 슬래시가 있는 올바른 심볼릭 링크를 만듭니다. 잘못된 슬래시 유형으로 생성된 심볼릭 링크는 VS Code와 같은 앱에서 사용할 수 없는 것처럼 보입니다. 그것도 아마도 이해할 수 있습니다.

NB 심볼릭 링크가 절대 경로를 가리키도록 하는 추가 이점이 있는 심볼릭 링크 대상에서 convert-item 를 실행하여 이 문제를 해결하는 것은 매우 쉽습니다(적절할 수 있음).

NB 심볼릭 링크가 절대 경로를 가리키도록 하는 추가 이점이 있는 심볼릭 링크 대상에서 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를 참조하세요.

상대 심볼릭 링크 동작과 문제 제기 https://github.com/PowerShell/PowerShell/issues/13064 에 대한 철저한 조사에 대해 @mklement0 에게 감사드립니다. 내가 가진 특정 문제와 이 토론에 대한 후속 조치를 위해 메모를 작성했지만 실제로 https://github.com/PowerShell/PowerShell/issues/13064 의 모든 내용을 다루었으며 실제로 방법을 알려준 것 같습니다. PowerShell 테스트를 작성하기 위해(저는 PowerShell을 처음 사용합니다).... 건배!

나는이 문제를 모든 세부 사항에 따르지 않았으므로 누락 된 사항이 있으면 실례합니다. 초기 문제는 플랫폼 간 표준화된 경로 구분자(슬래시 가능성 있음)였습니다. @iSazonov 는 이제 이 문제를 종료했습니다. 이슈 마감 이벤트를 구독한 사람들이 따라갈 수 있도록 이것이 더 이상 유효하지 않다고 생각하는 이유를 간략하게 설명해 주시겠습니까?

https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 에 따라 유효하지 않았습니다.

위에서 @lzybkr 이 제안한 것과 같은 것은 여전히 ​​완벽하게 합리적이며 구현하기 쉽습니다. 요약하자면:

경로 완성이 완성 텍스트에 명시적으로 나타나는 경로 구분자를 사용했다면 좋을 텐데, 없으면 기본적으로 플랫폼 기본 구분자로 설정됩니다.

그런 다음 Windows에서 / 가 여전히 중단되는 드문 경우를 피하는 것은 사용자의 책임입니다( 위 참조).

이것은 powershell을 통해 wsl bash 스크립트를 실행할 때 정말 골치 아픈 문제를 야기합니다. 좋다:

bash .\updateTemplate.sh

이것은 자동 완성되어야합니다

bash ./updateTemplate.sh

이 문제에 대한 다른 해결 방법이 있습니까? 특히 PS가 bash/WSL 컨텍스트에서만 슬래시를 사용하여 경로를 자동 완성하면 완전히 괜찮을 것입니다.

이 문제에 대한 다른 해결 방법이 있습니까?

bash에 대한 사용자 정의 완성기를 만듭니다.

이 문제에 대한 다른 해결 방법이 있습니까?

bash에 대한 사용자 정의 완성기를 만듭니다.

어떻게 합니까?

이 문제의 근거 없는 종결에 대해 더 이상 논의하지 않습니까? 이것은 플랫폼 간 작업에 대한 주요 성가심입니다. 플랫폼 간 도구 또는 wsl을 통해 간접적으로 Linux 도구에 제공되는 경로를 자동 완성할 때마다 전체 경로를 통해 커서를 뒤로 이동하고 모든 단일 백슬래시를 슬래시로 개별적으로 교체해야 합니다. 아무도 이런 식으로 작업해서는 안 되며, Powershell을 명령줄로 사용할 수 없게 만듭니다.