A alternativa atual é forçar os usuários a normalizar os caminhos

O PowerShell já faz o trabalho para você e você não precisa normalizar os caminhos.
O PowerShell é muito fácil de usar aqui - os usuários podem usar barras com as quais se sintam confortáveis, independentemente da plataforma.
A prática recomendada é evitar o uso de caminhos literais e usar cmdlets de caminho.

A prática recomendada é evitar o uso de caminhos literais e usar cmdlets de caminho.

@iSazonov Sim e não.

Claro, se você estiver combinando segmentos de caminho, poderá usar cmdlets de caminho. Mas se você estiver escrevendo um script que faz referência a um caminho relativo com vários segmentos e se pretende que seu script funcione em várias plataformas, não fará isso.

Na visualização 3 do PowerShell 7 no Windows, a conclusão da guia conclui os caminhos usando uma barra invertida. Esse é o único lugar em que acho que estamos fazendo errado agora que o PowerShell é multiplataforma. Deve haver pelo menos uma opção para selecionar o caractere separador de diretório que você deseja usar no Windows como parte da conclusão da guia: [System.IO.Path]::DirectorySeparatorChar ou [System.IO.Path]::AltDirectorySeparatorChar . Dado onde estamos hoje, suspeito que a maioria das pessoas que fazem qualquer trabalho de plataforma cruzada gostaria de concluir a guia de caminhos para usar AltDirectorySeparatorChar no Windows por padrão, mas até onde eu sei, não há como fazer isso .

@chriskuech : Além da conclusão da guia dos caminhos, existem outros lugares onde você sente que AltDirectorySeparatorChar não está sendo usado onde você gostaria de ter uma opção para que ele fosse usado em vez de DirectorySeparatorChar ? Não consigo pensar em nenhum.

@KirkMunro , você está dizendo que existe uma maneira (pelo menos parcialmente implementada) de normalizar caminhos no PowerShell hoje? Em caso afirmativo, funcionará na versão 6.x mais recente? Os casos de uso com os quais eu estava tendo problemas eram variáveis ​​automáticas e comandos *-Path .

@iSazonov , a solução proposta não teria funcionado para o meu cenário porque gerei uma lista de caminhos no Windows, gerei uma lista de caminhos no Linux e tentei compará-los, o que falhou devido aos separadores.

As variáveis ​​automáticas consistentemente não possuem um separador de diretório à direita, portanto, o PowerShell permite criar caminhos com literais. Ex:

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

Eu acho que isso é muito mais claro do que

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

então espero que possa funcionar no futuro, mesmo que não seja por padrão.

@chriskuech meu hábito pessoal se tornou algo como:

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

É um pouco mais claro, mas sim, não é perfeito.

Join-Path tem AdditionalChildPath que aceita array de strings.

@chriskuech Obrigado pelas informações adicionais.

Eu não estava sugerindo que o PowerShell suporta parcialmente a normalização de caminhos. Eu estava simplesmente dizendo que pessoalmente não gosto que o preenchimento de guias use uma barra invertida por padrão no Windows e uma barra invertida por padrão no Linux ou macOS.

Se eu pudesse ajustar alguma configuração para alterar isso para que a barra seja usada mesmo nos caminhos do Windows por padrão, eu faria essa alteração, e este é um lugar onde acho que pode haver uma oportunidade de facilitar o trabalho do PowerShell entre plataformas. Join-Path usa [System.IO.Path]::DirectorySeparatorChar como separador de caminho também. Idealmente, se houvesse uma configuração para definir o separador de caminho desejado ao escrever scripts (porque devemos ser capazes de escrever scripts facilmente da maneira que queremos, independentemente da plataforma em que escolhemos escrevê-los), isso seria refletido na conclusão de guias de caminhos e Join-Path também.

Essas necessidades pessoais à parte, gostaria de saber se um cmdlet Compare-Path seria útil. Ele pode normalizar os separadores de caminho e até mesmo comparar caminhos absolutos com caminhos relativos resolvendo caminhos relativos antes que a comparação seja feita se um dos caminhos for absoluto.

Bem, obtemos normalização _específica da plataforma_ em Convert-Path e Resolve-Path :

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

Assim, talvez como uma alternativa à introdução de um cmdlet Compare-Path , Convert-Path e Resolve-Path poderiam ser estendidos para oferecer suporte a um switch -UseSlash (nome negociável).

Separadamente e complementarmente, o mecanismo de preferência opt-in para usar / no Windows que Kirk sugere também pode se aplicar a Convert-Path e Resolve-Path (além do preenchimento de guias e Join-Path ).

O problema no momento é que Convert-Path e Resolve-Path só funcionam com caminhos _existing_, mas isso é algo que vale a pena mudar por si só, como @jaykul sugeriu há muito tempo - veja #2993

Eu acho que seria bom se a conclusão do caminho usasse o separador de caminho que aparece explicitamente no texto de conclusão e, se não houver, o padrão será o separador nativo da plataforma.

Portanto, no Windows, c:\w completa para c:\Windows\ e c:/w completa para 'c:/Windows/'.

Eu acho que isso cobriria a maioria dos aborrecimentos sem exigir uma opção de configuração e, na verdade, é preferível porque você ocasionalmente pode precisar do outro formulário por qualquer motivo.

@lzybkr , eu gosto da ideia, também à luz de uma preocupação em relação a uma solução baseada em variável de configuração / preferência que eu esqueci de mencionar: o problema de escopo; com o escopo _dynamic_ usual, o código que faz suposições fixas sobre separadores de caminho pode quebrar (o que tem ecos de https://github.com/PowerShell/PowerShell-RFC/issues/7).

@lzybkr e quando ambas as barras são usadas? C:\Program Files/A -> ?

Tantas opções - aleatórias, alternadas cada uma, sempre barra b/c é o único separador de caminho verdadeiro, etc.

Mais a sério, talvez apenas escolha o último usado, que provavelmente é digitado pelo usuário, enquanto outros podem não ser.

@lzybkr : Mas há um problema:

Se você iniciar _sem_ um separador de caminho, para fazer referência a um arquivo/pasta no _diretório atual_, o PowerShell terá que fazer a escolha para você, pelo menos com base no algoritmo de conclusão atual que se expande para .\<filename> ou ./<filename> / .\<folder>\ ou ./<folder>/ , de acordo com a plataforma.

Para _files_ como _arguments_, poderíamos contornar esse problema expandindo fil para apenas file , por exemplo (sem prefixo .\ / ./ ).

Contudo:

• para _executables_ , o prefixo .\ / ./ adicionado automaticamente é uma conveniência valiosa se a intenção for realmente executar um script localizado no diretório atual.

• para _diretórios_, da mesma forma, expandir para algo com um _separador de caminho final_ ( <folder>\ ou <folder>/ ) também é valioso.

Em ambos os casos, não há ação do usuário para sugerir o separador preferencial.

Dito isso, talvez a solução seja: se você quiser controlar o separador, _iniciar _manualmente com_ ./ ou .\ e fazer com que o preenchimento da tabulação respeite isso.

Este problema foi marcado como respondido e não teve nenhuma atividade por 1 dia . Foi fechado para fins de limpeza.

@iSazonov : Isso não é realmente respondido e deve ser reaberto para permitir que a discussão em andamento continue a resolver isso. O OP nem sequer teve a chance de responder às perguntas feitas a ele.

Acho que respondi todas as perguntas para mim, mas me avise se não o fiz. Eu também não sei porque esta questão está encerrada. Não foi feito para ser um tópico de discussão, mas sim uma solicitação de recurso.

A questão raiz em questão:

• Uma ferramenta multiplataforma deve ter um comportamento não multiplataforma por padrão?
• Em caso afirmativo, deve haver uma maneira de executar globalmente o PowerShell em um modo "multiplataforma"?

Eu acho que forçar os desenvolvedores a normalizar manualmente as strings com cmdlets é definitivamente um movimento errado. Não vejo nenhum cenário em que usar / por padrão causaria problemas no Windows porque o PowerShell, como mencionado anteriormente, é muito bom para lidar com os dois tipos de barras. A menos que alguém possa fornecer situações convincentes em que isso causaria erro, por que não usar / por padrão? Talvez esse problema precise ser movido para um RFC.

À medida que mais pessoas migram para a nuvem, mais e mais pessoas desenvolvem código do PowerShell no Windows e o executam no Linux. Certamente haverá um ponto no futuro (se ainda não tiver passado) em que o número de usuários que preferem o verdadeiro comportamento multiplataforma excede qualquer um que se sinta fortemente em manter \ no Windows.

@chriskuech : Foi mal, eu não fiz a pergunta especificamente para você. Eu queria saber se você sentiu que um cmdlet Conpare-Path o ajudaria. Essa pergunta de lado, porém, gostaria de ver as opções de normalização também.

@KirkMunro Não tenho certeza se Compare-Path ajudaria, porque no caso de uso original (comparando caminhos no Linux e no Windows), o sistema de arquivos raiz é diferente, então tenho que chamar Resolve-Path -Relative . Nesse ponto, o caso de uso de comparação é apenas uma linha: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

No entanto, estou muito hesitante em endossar qualquer solução baseada em cmdlet, pois ela não resolve o problema raiz e não permitirá a interpolação de strings para caminhos ou exigirá alterações de código para cada definição de string de caminho. Especificamente, Compare-Path não corrigirá todos os meus caminhos registrados com barras mistas.

@KirkMunro @mklement0 O problema não está bloqueado e todos podem fazer comentários.
Temos muitos problemas sem novos comentários e progressos. O status aberto perdeu seu significado.
Como mantenedor, pretendo ser mais exigente para estimular as discussões a se tornarem especificações mais rigorosas que podem facilmente se transformar em PRs.
Quanto ao problema, ele se transforma em infinito - a solicitação inicial era "usar barra no Windows" e depois "comparar caminhos". Qual é o próximo? Remoto? Está aberto para continuar, mas será fechado.
Enquanto apenas uma proposta real de Jason estava acima (para melhorar a conclusão) e poderíamos abrir um problema de rastreamento e fechá-lo por PR real.

Para ser claro, o problema ainda é "usar barra no Windows". "Comparar caminhos" foi mencionado apenas como um (entre vários) exemplos motivadores.

Proposta
Implemente um comportamento de plataforma cruzada verdadeiro, em que o delimitador de caminho é padronizado para / em todas as plataformas, a menos que o usuário esteja completando com tabulação um caminho que já contém \ . Eu esperaria que isso fosse ocultado como um recurso experimental por enquanto, mas eu deveria pelo menos ser capaz de habilitar um recurso "maximizar o comportamento de plataforma cruzada" no meu código para otimizar a experiência de desenvolvimento dos desenvolvedores do Windows direcionados ao Linux.

Se isso não for razoável, gostaria de saber por que e se há documentação orientando quando o design do PowerShell diverge entre as plataformas.

@iSazonov : Os mantenedores do repositório PS não devem ignorar os problemas dos usuários sem discussão. Você respondeu originalmente sem ter tempo para entender as necessidades do OP, marcando o problema como respondido, mas o problema não foi postado como uma pergunta, foi postado como uma solicitação de recurso e, como pode ser visto pela discussão, é claramente não respondido".

O status aberto perdeu seu significado.

Quem diz? Isso absolutamente não é verdade. Um problema aberto é aberto e um problema fechado é encerrado. Essas duas distinções têm um significado muito claro. Eu só olho para questões encerradas se elas são minhas e eu quero voltar para verificar alguma coisa. Em raras ocasiões, posso procurar questões fechadas para discussões sobre um determinado tópico. Mas 90% ou mais do meu tempo em questões está em questões em aberto, como deveria ser. A única coisa que obscurece a linha entre os dois e faz com que os problemas em aberto percam seu significado é fechá-los sumariamente antes de serem resolvidos, como você fez com esse problema.

(A discussão) está aberta para continuar, mas será encerrada.

Com base nessa abordagem de gerenciamento de problemas, você está forçando as pessoas a perder a distinção entre aberto e fechado, de modo que elas precisam pesquisar todos os problemas em vez de se concentrar nos problemas abertos, o que significa verificar os problemas abertos de 2K mais os problemas fechados de 4K para discussões relevantes para eles em vez de se concentrar apenas nas questões em aberto. Essa é uma estratégia de gerenciamento de problemas quebrada e falha.

Quanto ao problema, ele se transforma em infinito - a solicitação inicial era "usar barra no Windows" e depois "comparar caminhos". Qual é o próximo? Remoto?

Isso é ridículo. A discussão está focada em lidar com o Windows tendo uma barra invertida como padrão quando você está escrevendo scripts para plataformas cruzadas. Manteve-se focado nesse tema. Você está tentando fazer parecer que não está focado em tudo.

@iSazonov , concordo que há muitos problemas em aberto; no entanto, o fato de haver muitas questões em aberto não significa que devemos ser desdenhosos e encerrar a conversa prematuramente sobre novas questões. Devemos continuar a incentivar o feedback e estar abertos à discussão sobre o PowerShell em problemas em aberto, e apenas fechá-los quando estiverem realmente resolvidos. O volume de questões em aberto deve ser tratado de forma diferente.

Usuários fiéis do Linux? Conselhos incompreensíveis.
Você pode convencer a Microsoft. Peça que usem barras invertidas como caminhos de arquivos do sistema.

Gostaria de informar aqui que existem casos de uso em que são necessários caminhos literais com barras, mesmo no Windows.

Eu estava apenas escrevendo um script em que estava usando APIs .net para manipular e criar arquivos zip. Adicionando entradas ao arquivo zip com esta API:

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

Nesse caso específico, $entry é um caminho dentro do arquivo zip. Se eu simplesmente passar o caminho do Windows como retornado por vários cmdlets de caminho, todos os utilitários zip do planeta emitirão avisos sobre meu arquivo zip com as barras erradas.

Além disso, como um usuário e desenvolvedor linux de longa data, adoro o powershell e tenho me divertido muito aprendendo. Eu tenho me divertido jogando com meu novo núcleo do servidor Windows sobre ssh no powershell 7 também, e publiquei scripts que funcionam perfeitamente com o powershell no linux. Fiquei surpreso com o quão bem isso funciona. Na verdade, o powershell será minha primeira escolha para alguns programas/scripts que quero que sejam multiplataforma.

Mas ainda me deixa triste ver todas as minhas conclusões de guias serem reescritas com barras invertidas.

Eu uso caminhos como /users/foo/somefile no Windows o tempo todo e é isso que eu quero usar.

A maioria das APIs do Windows suportam muito bem as barras. Percebo que existem algumas exceções, com utilitários e talvez APIs, ou seja, algumas invocações de cmd.exe, mas eu só quero definir algo no meu $profile para que, por padrão, todos os meus caminhos tenham barras, a menos que eu esteja usando barras invertidas explicitamente.

Isso seria inofensivo para usuários e desenvolvedores do Windows acostumados com as barras invertidas porque eles simplesmente não usariam essa configuração e o padrão seria desativado. Claro, eles podem decidir usá-lo também se, por exemplo, decidirem escrever mais scripts e módulos multiplataforma.

Quero essa configuração para meus scripts e módulos também, para não ter problemas inesperados como o que mostrei acima.

Os usuários do @iSazonov podem usar barras com as quais se sintam confortáveis, independentemente da plataforma.

Isso significa que posso configurar o PowerShell para usar barras, pois isso é mais confortável para mim como usuário? Gostaria de alterar o caminho exibido no prompt, bem como o preenchimento automático da guia, que atualmente transforma barras invertidas em barras invertidas.

@aaronfranke , não, atualmente não há como configurar o PowerShell dessa maneira; Eu acho que o @iSazonov estava tentando dizer é que quando você digita manualmente um caminho, você é livre para escolher entre \ e / (e você pode até misturá-los em um único caminho) .

Considerando a versatilidade, um novo símbolo de caminho deve ser ativado em vez de / e ，Símbolos tradicionais aumentam a dificuldade de conversão entre plataformas

Acho que o @iSazonov estava tentando dizer que, quando você digita manualmente um caminho, fica livre para escolher entre e / (e pode até misturá-los em um único caminho).

Sim, é o design do PowerShell.

Esta não é uma resolução dos problemas que foram levantados aqui, como a substituição forçada de seus separadores de caminho durante a conclusão ou a capacidade de configurar cmdlets de caminho para usar o separador de caminho de sua escolha, se abrirmos problemas específicos separados para eles ?

@rkitover Perguntei sobre esses cenários anos atrás (você pode encontrar o problema) sem nenhuma resolução. Isso me convence de que se trata de uma mudança cosmética, embora exija muito esforço. Se você está pronto para investir nessa área e puxar um PR, só então faz sentido abrir uma nova discussão.

CP/M e clones usam / para opções, exemplos: DIR/P , CMD/CECHO . Estes são comandos válidos. Se substituirmos \ por / em todos os lugares, temo que mal-entendidos ruins possam acontecer.

1. Ninguém mais usa CP/M.

2. Usar / para opções e caminhos ao mesmo tempo funciona bem no Windows em meus testes.

3. As ferramentas modernas usam - para opções, incluindo ferramentas do PowerShell e outras ferramentas da Microsoft, como .NET. O uso / para opções deve ser mantido para compatibilidade com versões anteriores, mas os usuários não terão nenhuma confusão com ferramentas modernas.

Além disso, gostaria de observar que a barra / é um nome de caractere inválido em nomes de arquivos Win32:

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

Essência

Caracteres inválidos para nomes de arquivos do Windows

Caracteres inválidos para nomes de arquivos do Windows. GitHub Gist: compartilhe instantaneamente código, notas e trechos.

Eu só quero salientar que comecei a usar barras apenas em scripts de plataforma cruzada, etc., e tive um problema com links simbólicos.

Como exemplo, execute

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

no Windows e você não poderá abrir TestScript8.ps1 no VS Code no Windows.

@markm77 , você descobriu um _bug_ - você pode criar um novo problema para ele ? [_atualização_: consulte #13064]

Não que seja um argumento contra um mecanismo opt-in para o padrão de / , @aaronfranke , mas observe que existem poucos casos extremos em que / em vez de \ ainda quebra coisas no Windows; por exemplo:

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

Aspas duplas no caminho só ajudam com caminhos _directory_, curiosamente - veja https://stackoverflow.com/a/43297482/45375 , que também mostra que a biblioteca Excel COM Automation não suporta / .

Estouro de pilha

Por que o PowerShell não deseja salvar meu arquivo como CSV

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Abra o documento do Excel e puxe a planilha 'Sheet1' $Excel = New-Object -Com Excel.Application $Pasta de trabalho...

@markm77 , você descobriu um bug - você pode criar um novo problema para ele?

Mas isso é um bug do PowerShell? O PowerShell cria o link simbólico correto com a barra especificada conforme verificado examinando o link simbólico usando dir . Parece que um link simbólico criado com o tipo de barra errado pode ser inutilizável em aplicativos como o VS Code. O que também é compreensível, talvez.

NB, é muito fácil contornar esse problema executando convert-item em destinos de link simbólico que tem o benefício adicional de garantir que links simbólicos apontem para caminhos absolutos (provavelmente apropriados).

NB, é muito fácil contornar esse problema executando convert-item em destinos de links simbólicos, o que tem o benefício adicional de garantir que links simbólicos apontem para caminhos absolutos (provavelmente apropriados).

Inapropriado, vai quebrar ao remontar 😞

Inapropriado, vai quebrar ao remontar 😞

Comentário justo, não remonto (isso é para trabalho de desenvolvimento local) e tenho um script para geração de link que posso executar a qualquer momento. join-path é obviamente a outra solução ou ainda melhor seria uma opção new-item para garantir que os links sejam apropriados para a plataforma.

Consulte #12797

Mas isso é um bug do PowerShell?

Embora você possa argumentar que no _Windows_ é um bug do WinAPI, dado que \ e / geralmente são suportados de forma intercambiável, é definitivamente um bug em plataformas do tipo Unix se você fizer o inverso e passar um caminho baseado em \ como o caminho -Target - nessas plataformas, apenas / é suportado nativamente (somente o PowerShell permite que você use \ como uma alternativa, que vem com seus próprios problemas - veja #9244), e é responsabilidade do PowerShell traduzir algo como .\TestScript.ps1 para ./TestScript.ps1 ao criar o link simbólico.

Corrigir isso - fazendo com que o PowerShell normalize o caminho para usar o separador _platform-native_ (primário) - também corrigirá o problema no Windows.

@iSazonov , #12797 fundamentalmente ativou o suporte para caminhos _relative_ como destinos de link simbólico, mas o problema em questão é a falta de normalização do separador nativo da plataforma, que torna os links simbólicos resultantes quebrados.

@iSazonov Consulte o nº 13064 para saber o que ainda está quebrado no PowerShell Core 7.1.0-preview.4 (que deve incluir o nº 12797, certo)?

Obrigado @mklement0 pelo que parece ser uma investigação completa do comportamento relativo do link simbólico e o aumento do problema https://github.com/PowerShell/PowerShell/issues/13064. Eu havia feito uma anotação para acompanhar ainda mais o problema específico que tive e essa discussão, mas, na verdade, parece que você cobriu tudo em https://github.com/PowerShell/PowerShell/issues/13064 e, de fato, me ensinou como para escrever testes do PowerShell (sou novo no PowerShell).... Saúde!

Eu não acompanhei essa questão em todos os detalhes, então me desculpe se eu perder alguma coisa. O problema inicial foi um separador de caminho padronizado entre plataformas (potencialmente uma barra). @iSazonov agora encerrou este problema. Você pode, por favor, dar uma visão geral do motivo pelo qual você acha que isso não é mais válido para que as pessoas que se inscreveram em eventos de fechamento de problemas possam acompanhar?

Nunca foi válido, conforme https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 .

Algo como o que @lzybkr propôs acima ainda é uma coisa perfeitamente razoável - e presumivelmente fácil - de implementar; para recapitular:

Eu acho que seria bom se a conclusão do caminho usasse o separador de caminho que aparece explicitamente no texto de conclusão e, se não houver, o padrão será o separador nativo da plataforma.

É então responsabilidade do usuário evitar os raros casos extremos em que / ainda quebra no Windows (veja acima ).

Isso causa uma verdadeira dor de cabeça ao executar scripts wsl bash via powershell. Como:

bash .\updateTemplate.sh

Isso deve ser preenchido automaticamente para

bash ./updateTemplate.sh

Existe alguma outra solução para este problema? especificamente, eu ficaria totalmente bem se o PS completasse automaticamente o caminho com barras apenas no contexto bash/WSL.

Existe alguma outra solução para este problema?

Crie um completor personalizado para o bash.

Existe alguma outra solução para este problema?

Crie um completor personalizado para o bash.

Como você faz isso?

Não estamos recebendo mais discussão sobre o encerramento infundado desta questão? Este é um grande aborrecimento para o trabalho multiplataforma. Toda vez que eu autocompleto caminhos que são alimentados para ferramentas de plataforma cruzada ou indiretamente através de wsl para ferramentas Linux, eu tenho que marchar meu cursor para trás por todo o caminho e substituir individualmente cada barra invertida por uma barra. Ninguém deveria ter que trabalhar dessa maneira, e isso realmente torna o Powershell como uma linha de comando quase insustentável.