Powershell: Crie pwsh como um nome mais curto para chamar o powershell.exe

Eu gostaria de um curto apelido também, mas isso é por isso que não se ir com posh quando fomos primeiro a sair (nós conversamos sobre isso no comprimento). Também parece ser um pacote atualizado.

Aberto a outras sugestões, mas a maioria das * sh mais óbvias foi aceita. Depois do único alias wget / curl, eu realmente gostaria de evitar colidir com outros pacotes por aí, mesmo que eles sejam menos comuns.

Eu não sou muito louco por essa ideia, mas que tal pwsh ?

Nunca gostei de chique como encurtamento de PowerShell. pwsh parece melhor, mas uma pesquisa rápida na Internet levanta alguns possíveis problemas. se vamos fazer isso, eu sugiro o mais curto possível, então que tal apenas o ps?

OK - esqueça isso - acabei de perceber que ps é um apelido para get-process. isso seria muito confuso

Estou ficando com um déjà vu forte agora. 😉

Agradeço a legibilidade do PowerShell (quando não estou usando aliases), então executar powershell funciona bem para mim.

ps é um comando existente no Linux.

Algumas outras idéias são: pscmd , psc , monad , psh , pshell

Definitivamente, há retornos decrescentes com esses nomes, embora eles realmente salvem alguma coisa ou apenas adicionem confusão desnecessária, se estiverem disponíveis.

CoreSh , pcs , psc

Que pena que o mosh está ocupado. psh é levado. [pshell] retorna muitos resultados. Curiosamente, uma pesquisa por msh no Bing e no Google traz muitos resultados para PowerShell (chamando-o de Microsoft Shell), embora exista um msh no Unix (talvez não seja muito usado)

😄 S #, P #

@ PowerShell / powershell-Committee discutiu isso e está aberto a ter um nome de link simbólico mais curto, mas não podemos atacar ninguém que já exista. prsh parece ok.

Espera espera! Entendi: ^sh - ou era **sh ? (jk).

prsh parece reasonabe - mais fácil de digitar do que pwsh , por exemplo, embora pwrsh - apesar de ter 1 caractere. mais - também vale a pena considerar, visto que "pwr" é uma abreviação conhecida para "poder".

Outra opção, possivelmente _complementar_: fornecer uma _variável automática_ cujo valor _invariavelmente_ reflete o mesmo caminho do binário que iniciou a sessão atual.

bash tem $BASH para isso.

A vantagem dessa abordagem é que ela é imune a variações / manipulações de $env:PATH .

Já temos $PSHOME - indiscutivelmente, algo como $PS não é muito exagerado.

Dito isto, está relacionado à discussão sobre não poluir o namespace global com variáveis ​​automáticas - consulte # 4216.

.Net Core, CoreFX, CoreCLR, PowerShell Core - podemos considerar o "core" como base.

pscore me parece bem, mesmo que não termine com sh embora outros membros do Comitê o tenham vetado

pscore ou coreps - LGTM.

Podemos nos lembrar de monad e msh (mencionados acima).

Eu gosto de pwrsh mais até agora. pscore também não é ruim, embora esteja ficando meio comprido com 6 caracteres. Quatro ou menos caracteres é provavelmente o ideal, mas eu poderia viver com os 5 caracteres exigidos por pwrsh .

Minha preocupação em incorporar a palavra "core" é que ela não carrega nenhuma informação útil em plataformas Unix, onde não há outra edição da qual precise ser distinguida.

@rkeithhill, que tal pscx , ha! Experiência do PowerShell Core. Porém, isso me fez pensar em outro, pscsh , PowerShell Core Shell.

Estou indeciso sobre alguns dos mesmos nomes também. Gosto da legibilidade de pwrsh e pscore mas concordo que 5 caracteres é o limite. 5 caracteres cobrem a primeira palavra power e mais do que isso, você também pode digitar a palavra completa. monad é um ótimo ovo de páscoa e legível, mas confuso para aqueles que não conhecem o background do PowerShell. Os 4 caracteres prsh também funcionam bem.

Seria bom criar uma lista final de nomes que podem ser usados ​​e fazer uma votação oficial como a equipe do Edge fez. Se houver alguma comunidade PS ou eventos oficiais futuros, links para a enquete podem ser fornecidos para tentar alcançar um público maior.

@ dragonwolf83 :

pscsh está perigosamente perto de csh - uma associação que devemos evitar.

Novamente, não vejo nenhum benefício em incluir a palavra "core", especialmente se houver uma chance de que as edições sejam unificadas um dia (e no _Windows_, as pessoas parecem ter vivido confortavelmente sem um nome curto para _Windows PowerShell_ por uma boa década) .

Obscuridade acordada de monad .

Meu voto pessoal é para pwsh , prsh ou pwrsh .

PS: No caso de _Windows PowerShell_ também precisar de um nome curto, simplesmente prefixar w pode ser a solução, embora entre meus favoritos isso realmente apenas (razoavelmente) saia do teclado como wprsh , então em No cenário do nome curto de duas edições, meu voto é para o par prsh / wprsh .

Minha preocupação em incorporar a palavra "core" é que ela não carrega nenhuma informação útil em plataformas Unix, onde não há outra edição da qual precise ser distinguida.

:-) Devemos renomear .Net Core?

@iSazonov : Devemos renomear o Windows PowerShell como "Windows PowerShell .NET Framework [FullCLR]?"

Eu votaria em psh - o projeto que você cita como uma colisão não teve um lançamento em 10 anos e nunca esteve em repositórios de pacotes em qualquer caso.

@Jaykul :

psh ? Eu não sei - precisa de mais "núcleo", se você me perguntar.

Brincadeiras à parte: excelente ponto sobre o status do projeto e sua ausência de repositórios de pacotes.

psh tem meu voto (e wpsh para Windows PowerShell).

(Pronuncia-se 'pshaw' e 'whiplash', respectivamente).

psh tem meu voto (e wpsh para Windows PowerShell).
(Pronuncia-se 'pshaw' e 'whiplash', respectivamente).

Tem certeza de que não podemos simplesmente usar posh no Windows e considerá-los nojentos? 🤡

Pish-tosh! Isso é muita confusão para todo o mishpocha. 🤡

Eu votaria em psh - o projeto que você cita como uma colisão não teve um lançamento em 10 anos e nunca esteve em repositórios de pacotes em qualquer caso.

Nenhum problema de direitos autorais?

Sem problemas de direitos autorais?

Espero que alguém que realmente _conheça_ avalie, mas _pu paro_ é que isso não será uma preocupação por 2 motivos:

• psh não é o nome oficial do produto, apenas um inicialismo (falando mais vagamente, sigla) que é meramente um auxílio técnico (embora no uso popular possa eventualmente se tornar uma abreviação comum para o nome completo do produto; _é_ possível para inicialismos / acrônimos de marca registrada).

• Os problemas de marca registrada são frequentemente sobre a probabilidade de _confusão_ com marcas existentes, e pelo que vimos aqui, pelo menos no espaço do software parece não haver colisões (eu não acho que o criador do virtualmente extinto psh repo se importará ou até mesmo terá um processo legal).

Caso alguém queira experimentar / precisar de uma solução provisória:

Esta é uma solução com todos os aliases que define os aliases dentro e fora do PowerShell, em todas as plataformas suportadas: psh para PS Core e wpsh para Windows PowerShell.

• Execute o seguinte UMA VEZ para configurar aliases FORA do PowerShell (para cmd.exe no Windows, para bash no Unix):

  # Note: 
  #   * On Unix, this will define alias `psh` for *interactive* Bash sessions,
  #     via initialization file ~/.bashrc (Linux) or ~/.bash_profile (macOS).
  #   * On Windows, this defines doskey.exe-based aliases `psh` and `wpsh`
  #     via registry key [HKEY_CURRENT_USER\Software\Microsoft\Command Processor],
  #     value 'AutoRun', and even though *any* cmd.exe instance will run
  #     these alias definitions, they only work in *interactive* ones.
  #     Note that both aliases open a new window.
if ($env:OS -eq 'Windows_NT') {
  $cmd = 'doskey wpsh=start powershell.exe & doskey psh=powershell.exe -nologo -command "psh"'
  $currVal =  try { Get-ItemPropertyValue 'HKCU:\Software\Microsoft\Command Processor' AutoRun } catch {}
  if (-not (Select-String -Quiet -SimpleMatch -Pattern "$cmd" -InputObject $currVal)) {
    if ($currVal) { $cmd += " & $currVal" }
    Set-ItemProperty 'HKCU:\Software\Microsoft\Command Processor' AutoRun $cmd
  }
} else {
  $cmd = 'alias psh=powershell'
  $initFile = ("$HOME/.bashrc", "$HOME/.bash_profile")[(uname) -eq 'Darwin']
  if (-not (Select-String -Quiet -LiteralPath $initFile -Pattern "^\s*$cmd\b")) {
    Add-Content -LiteralPath $initFile -Encoding utf8 "`n$cmd"
  }
}

• Coloque o seguinte em seu $PROFILE para definir os mesmos aliases dentro do PowerShell - funciona tanto no PS Core quanto no Windows PS:

  # ===
  # Portable alias definitions for PowerShell Core (`psh`) 
  # and, on Windows, for Windows PowerShell (`wpsh`) too.
  #
  # Place them in $PROFILE.
  #
  # * On Unix, invoking `psh` always runs the new instance in the current terminal window.
  # * On Windows, only invoking the same edition runs in the current console window.
  #   Invoking the respective other edition opens a new window; if you also
  #   pass a command, add -NoExit to keep the new window open.
  #
  # ===
  if ($env:OS -eq 'Windows_NT') { # on Windows
    if ($PSVersionTable.PSEdition -eq 'Core') { # running in a PS Core session
      # PS Core alias: Invoke the same binary that started the current session.
      Set-Alias psh "$PSHOME\powershell.exe"
      # Windows PowerShell alias
      function wpsh {
        # Assume a fixed location in SYSTEM32.
        $exe = "$env:SYSTEMROOT\System32\WindowsPowerShell\v1.0\powershell.exe"
        $psModulePathSav = $env:PSModulePath
        try {
          # Note: We must remove all *\PowerShell\* entries from $env:PSModulePath, because they are Core-specific
          #       and interfere with module loading in Windows PowerShell.
          # Note that Start-Process -UseNewEnvironment is NOT an option: see https://github.com/PowerShell/PowerShell/issues/3545
          $env:PSModulePath = (($env:PSModulePath -split ';') -notmatch '[/\\]PowerShell[/\\]') -join ';'
          # Start Windows PowerShell in a new window.
          $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
          Start-Process $exe <strong i="18">@htArgs</strong>
        } finally {
          $env:PSModulePath = $psModulePathSav
        }
      }
    } else { # running in a Windows PowerShell session
      # PS Core alias:
      Function psh {
        # Given that the PS Core *.exe is not in $env:PATH as of PowerShell Core v6.0.0-beta.5, determine its location.
        # Since multiple versions may be installed, find the highest version installed.
        # Unfortunately on PSv5.1- [semver] ([System.Management.Automation.SemanticVersion]) is not available, so we fall back to the *.exe files' last-write timestamp.
        # WISHFUL THINKING: Set-Alias psh ((Get-ChildItem -Directory $env:ProgramFiles\PowerShell | Sort-Object -Descending { [semver] $_.Name })[0].FullName + '\powershell.exe')
        $exe = ((Get-ChildItem -File $env:ProgramFiles\PowerShell\*\powershell.exe | Sort-Object -Descending LastWriteTime)[0].FullName)
        # Note: The Core-specific module directories are automatically added to $env:PSModulePath, so no other action is required.
        # Start PS Core in a new window.
        $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
        Start-Process $exe <strong i="19">@htArgs</strong>
      }
      # Windows PowerShell alias: invoke the same executable that started the current session.
      Set-Alias wpsh "$PSHOME\powershell.exe"
    }
  } else { # on Unix (Linux, macOS)
    # Simply invoke the same binary that started the current session.
    Set-Alias psh "$PSHOME/powershell"
  }

E quanto a Paua ? Esta é uma referência à bela concha de paua (uma concha do mar da Nova Zelândia). Caso contrário, acho que psh é bom.

Você vende conchas do litoral da (Nova) Zelândia? (Brincadeira. Lindo mesmo.)

Isenção de responsabilidade: o seguinte é de interesse apenas para linguistas [hobby].

Foneticamente, paua só funciona para dialetos não róticos do inglês (por exemplo, Reino Unido, Nova Zelândia, Austrália).

E Bostonians.

@ PowerShell / powershell-Committee deve fechar para beta.8

Que tal Posh6

Que tal Posh6

Parece que ficaria desatualizado mais rápido do que colocar um número de versão em uma extensão de arquivo ...;)

Sim, mas um script de shell que o executa saberá qual versão está sendo executada.

Embora eu goste de posh , acho que a principal preocupação é que existe um pacote existente para Linux chamado Posh, então para evitar outro incidente de curl , acho que a próxima melhor opção é pwsh

Eu gosto de pwsh . Teria sido bom ter 10 anos atrás. Sinto falta de msh .

Eu voto em psh .
gnp / psh não foi comprometido em quase 5 anos. Pode muito bem ser abandonware.

Odeio dizer isso, mas essa é uma daquelas coisas em que pode ser muito difícil obter um consenso forte. : \

Neste ponto, para fechar as coisas e evitar qualquer tipo de colisão (mais "boa fé" do que legal), estou all-in em pwsh .

Deixe-me perguntar o seguinte: alguém tem um forte motivo para não optar por pwsh ?

Alguém ficaria preocupado se pwsh fosse o nome do executável e powershell fosse o link simbólico / atalho?

Antes de aprovarmos aqui, devemos responder o que é a versão "atual" e como vamos nos referir a ela e sua versão alvo?

@iSazonov não tenho certeza se entendi sua pergunta. Isso não está relacionado a powershell -v N se é isso que você está perguntando. Isso simplesmente permite usar pwsh vez de powershell (embora ainda apoiemos a grafia powershell ).

Minha preocupação é mais sobre links simbólicos como powershell -> powershell-6.0.0-beta.7
Se falarmos sobre a linguagem, gostamos de apelidos em sessões interativas porque nos dão um ambiente confortável, mas os apelidos são uma grande dor de cabeça nos scripts. Vejo o mesmo para o nome abreviado do PowerShell - provavelmente é bom para o tipo de velocidade, mas pode ser realmente um problema para a árvore de diretórios (links simbólicos).

Outro pensamento. Devemos pensar sobre o tipo de velocidade? Nem todos os casos propostos são bons nesta perspectiva.
O último pensamento é sobre a pronúncia. Interessante, em russo usamos "пош" ("posh") e hipocorismo "пошик" ("poshik") desde o nascimento do PowerShell. Eu acho que qualquer homem russo vai votar em "posh" ou "psh".

Só para ficar claro, pwsh não seria um alias (em termos do PowerShell), deveria ser algo que você pudesse chamar de cmd.exe ou de um arquivo em lote conforme existe fisicamente. Embora não esteja claro para mim como realmente implementamos isso, se quisermos oferecer suporte a um nome abreviado e powershell sem ter dois executáveis ​​(embora poweshell.exe seja relativamente pequeno ...).

Quanto a posh e psh vs pwsh , a principal preocupação com posh e psh é que eles já existem (independentemente de quão proeminentes sejam está). Tivemos um problema no início com nosso alias curl pois ele entrava em conflito com uma ferramenta nativa existente e (talvez sejamos excessivamente cautelosos aqui) estamos tentando evitar uma situação semelhante com a mão curta, por isso está inclinado para pwsh . Talvez se eu digitar pwsh frequência, as pessoas se acostumarão com isso :)

Outro lado. Como resolvemos o mesmo no PowerShell? Sugerimos apelidos de usuários e IntelliSense para alimentar a digitação.
Quando discutimos os apelidos em uma das discussões aqui, dissemos que todos os apelidos atuais não deveriam ser somente leitura - devemos permitir que os usuários removam / alterem quaisquer apelidos. Em outras palavras, os aliases não devem ser exclusivamente padrão. Apenas nomes de cmdlets básicos devem ser padrão. Deste ponto de vista, não devemos oferecer um alias "padrão" para "powershell" - qualquer comunidade ou distributiva deve ser capaz de escolher o nome que gosta e que corresponde ao seu espírito, também poderia oferecer IntelliSense também.

@ SteveL-MSFT - Acho que 'pwsh' provavelmente vai ficar bem com as pessoas.

Dito isso, vocês mencionaram o incidente do curl como uma razão para não usar 'psh'. Acho isso problemático, pois você está simplesmente se encaixando (nós) em um canto ao traçar paralelos muito longe!

'curl' é uma das ferramentas mais usadas no mundo Linux. É aconselhável ser excessivamente cauteloso para não repetir 'curl' snafu para software 'vivo' / 'ativo' , mas por que essa cortesia deveria ser estendida ao abandonware ?

Deixe que o incidente do curl nos ensine uma lição, mas não a lição errada.

Para apoiar o conselho de @AdilHindistan , deixe-me reiterar a análise direta de

Eu votaria em psh - o projeto que você cita como uma colisão não teve um lançamento em 10 anos e nunca esteve em repositórios de pacotes em qualquer caso.

Em outras palavras: O fato de que psh aparentemente nunca fez parte dos (principais) repositórios de pacotes (eu apenas verifiquei apt (Ubuntu, Debian) e yum (Fedora, RedHat)) - isto é, sempre foi um _produto de nicho_ - _e_ que pode, para todos os efeitos, ser considerado abandonado após mais de 10 anos de inatividade o torna um candidato perfeito.

(Em contraste, o fato de posh ainda ser um pacote disponível via apt , independentemente de seu status de manutenção, desqualifica-o, em minha opinião.)

Eu concordaria com os pontos apresentados de que psh é uma opção viável e deve ser considerada

Quanto a como _implementar_ o nome abreviado como um link simbólico / stub, assumindo que o nome do executável real permanecerá powershell[.exe] :

Vamos supor que o nome abreviado será, digamos, psh (apenas para escolher um dos nomes discutidos, aleatoriamente).

Plataformas Unix

O instalador terá _adicionalmente_ que fazer o equivalente ao seguinte:

# Linux
/usr/bin$ sudo ln -s powershell psh

# macOS
/usr/local/bin$ sudo ln -s powershell psh

Em outras palavras: crie um link simbólico adicional chamado psh que simplesmente aponta para o link simbólico powershell .

No macOS, isso resultaria em uma cadeia de links simbólicos como a seguinte:

/usr/local/bin/psh@ -> /usr/local/bin/powershell@ -> /usr/local/microsoft/powershell/6.0.0-beta.7/powershell

Qualquer shell de chamada, incluindo o próprio PS Core, seria, portanto, capaz de usar psh como uma alternativa mais curta para powershell .

janelas

No Windows, as coisas são mais complicadas:

• pelo menos a partir do beta.7, de _outside_ de PS _Core_, é apenas _Windows_ PowerShell que está no PATH.
• Deve haver atalhos distintos para Windows PowerShell vs. Powershell Core para invocação direcionada: psh para PS Core e wpsh para Windows PS (este nome também deve servir, porque também não está em uso nos repos apt e yum ).

Windows PS

_Windows_ PS poderia definir links simbólicos - um em cada $env:SystemRoot\System32\PowerShell\v1.0 (64 bits) e $env:SystemRoot\SysWOW64\PowerShell\v1.0 (32 bits) da seguinte maneira:

Set-Location $PSHOME
cmd /c mklink wpsh.exe powershell.exe

Em virtude de $PSHOME estar em $PATH , qualquer shell, incluindo o PS Core e o próprio Windows PS, poderia então invocar o Window PS como wpsh .

PS Core

O arquivo abreviado por si só poderia ser colocado em um diretório que está no PATH por padrão, o que permitiria a invocação mesmo sem o $PSHOME PS Core em si estar no PATH.

Considerações de 64 bits vs. 32 bits não se aplicam (PS Core é de 64 bits apenas), portanto $env:SystemRoot (normalmente, C:\Windows ) pode ser escolhido.

Infelizmente, o uso de _links simbólicos_ é pelo menos _não_ uma opção atualmente, porque o PowerShell Core se recusa a ser executado quando chamado por meio de um link simbólico que tem um nome diferente:

De uma sessão PS _elevada_:

Set-Location $env:SystemRoot   # typically, C:\Windows
cmd /c mklink psh.exe "C:\Program Files\PowerShell\6.0.0-beta.7\powershell.exe"

Invocar psh.exe falha da seguinte maneira:

The managed DLL bound to this executable: 'powershell.dll', did not match own name 'psh.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

Se alguém souber de uma maneira de contornar isso, diga-nos.

(Curiosamente, se você definir o link simbólico _sem extensão_ - psh vez de psh.exe - a invocação é bem-sucedida em princípio, mas nenhum parâmetro é passado.)

Uma solução alternativa é usar um arquivo em lote stub (novamente, execute a partir de uma sessão _elevated_ do PowerShell):

Set-Location $env:SystemRoot   # typically, C:\Windows
'@"%ProgramW6432%\PowerShell\6.0.0-beta.7\powershell.exe" %*' | Set-Content -Encoding ASCII psh.cmd

Qualquer shell de chamada, incluindo o Windows PowerShell e o próprio PS Core, pode usar psh como um atalho para invocar o PS Core.

@ mklement0 Eu estava pensando a mesma coisa em termos de usar um link simbólico no Linux / macOS e um arquivo em lote para Windows (e eu não faria nada pelo Windows PowerShell, pois isso ficaria apenas powershell ).

Parece que a coisa mais óbvia é que powershell é o principal e psh é o link, mas eu estava pensando que talvez devêssemos inverter para que psh fosse o nome de o exe e powershell é o link. O raciocínio é que, com um novo público em não Windows e para se diferenciar do Windows PowerShell, parece que a preferência é que as pessoas usem psh para se referir ao PowerShell Core e powershell é apenas fornecido para app-compat (talvez memória muscular para algumas pessoas durante a transição). No entanto, sei que nem todo mundo está convencido dessa ideia.

Se vermos que psh muito popular, podemos trocar powershell e psh .

Para adicionar um alias, pode ser útil https://stackoverflow.com/questions/2016722/one-dll-multiple-projects

Não gosto da ideia de psh se tornar o exe e do PowerShell ser relegado a um link. Você está desperdiçando 10 anos de fidelidade do público para potencial facilidade de uso em não-Windows, onde o tamanho do público é desconhecido e (pelo menos para começar) potencialmente pequeno.

Quanto mais vejo do PowerShell v6, mais parece que os usuários existentes do Windows estão sendo ignorados em uma tentativa de convencer os usuários não Windows a adotar o PowerShell. Onde termina esse processo?

@RichardSiddaway Não tenho a impressão de que a equipe do PowerShell está ignorando os usuários do Windows e sou principalmente um usuário do Windows com um Windows Phone. Fui eu que pedi isso não por algum conceito do Linux, mas pelos meus próprios desafios de mudar do cmd para o PowerShell.

O fato é que o Windows PowerShell é um produto maduro, mas não foi criado para várias plataformas. Para fazer este trabalho, o investimento inicial tem que ser maior para a plataforma cruzada no início, o que irá beneficiar os dois mundos. As coisas vão se equilibrar nos próximos lançamentos.

Além de aliases e aliases de parâmetro, não vejo muitos que afetem negativamente os usuários do Windows. Se houver um problema específico que seja motivo de preocupação, levante-o nessas questões. O debate é bom para a plataforma e precisamos garantir que nada de especial sobre o PowerShell seja perdido na transição.

@ SteveL-MSFT você pode fornecer um pouco mais de seu raciocínio para fazer psh ou pwsh se tornar o .exe? Se houver benefícios com isso, posso estar mais inclinado a favorecê-lo.

Ouch no arquivo em lote. Como fazer o link simbólico funcionar no Windows? Eu prefiro ter isso do que outra camada através do cmd.

@ dragonwolf83 Imagino que, com o tempo, as pessoas prefiram digitar 3 ou 4 caracteres em vez de 10, então, embora sempre apoiemos a digitação powershell , parece que de uma perspectiva de longo prazo, devemos otimizar para a versão mais curta

Seus comentários sobre o Windows PowerShell são perfeitos.

@ dragonwolf83 :

Ouch no arquivo em lote. Há alguma maneira de fazer o link simbólico funcionar no Windows?

Eu te escuto. Infelizmente, meu pedido de ajuda recebeu muito pouca atenção até agora.

powershell.exe tem 78k, seria tão ruim ter outros 78k como psh.exe ...

Ter 2 executáveis ​​duplicados pode ser uma solução fácil, mas também pode levar a confusão, pois posso imaginar que os usuários começarão a ponderar se há uma diferença entre os 2. Se eu fosse novo no PowerShell e visse 2 exemplos diferentes (por exemplo, no SO) que mostre como chamar / abrir o PowerShell, então eu imediatamente começaria a me perguntar qual exemplo devo escolher, porque presumo que há uma diferença ...

IMO, isso é bobo. O cmd.exe está amplamente oculto no Windows 10 1703, portanto, você raramente iniciaria o powershell.exe do shell legado.

Não é um grande fã disso - com que frequência você digita powershell que isso se torna um problema? (Além disso, problema de ciclismo total;)) No Windows 10 e Server 2016, defina "Substituir prompt de comando por Windows PowerShell quando eu clicar com o botão direito do mouse no menu iniciar ou pressionar Win + X" e é tão curto quanto Win + x, i ou no Linux , adicione um alias ao shell existente com o nome de sua preferência.

Dito isso, e quanto a:

• ps1 - após a extensão do arquivo no Windows, curto, fácil de digitar, memorável
• psps - é curto e digitável, mas deixa-se aberto a gíria 'típica M $ bloat'
• ips - como se para Invoke-PowerShell, não parece ser um pacote em repositórios RedHat ou Ubuntu e yum provides "*/ips" não mostra binários para confrontar em uma verificação rápida

Deixe-me perguntar desta forma: alguém tem um motivo forte para não ir com pwsh?

É feio e impronunciável, leva mais sílabas para dizer do que o próprio 'powerhell', não é particularmente fácil de digitar e parece que deriva do pwnd / pwnt do idioma da Internet.

Se em breve tivermos o PowerShell como shell padrão no Windows, o nome do arquivo (comprimento) se tornará sem importância.

PowerShell Core é um projeto portátil - temos que pensar no Unix também.

@ PowerShell / powershell-Committee discutiu isso e chegamos a um binário PSCore6 chamado apenas pwsh sem um atalho / alias adicional para powershell . O benefício é torná-lo explícito sem ambigüidade no Windows, esteja você usando o Windows PowerShell ou PowerShell Core. Em não Windows, é mais curto para digitar e mais consistente com outros nomes de shell. Com base no feedback do cliente, podemos sempre adicionar um link / atalho / alias powershell no futuro.

Meu voto é psh.exe.

@jandrusk O PR já foi mesclado ontem, então será pwsh.exe. Jeffrey já tweetou sobre isso aqui .

Viva o novo PassWord / Por-semana / PoliceWoman SHell!

Meu voto teria sido deixar como está.

Então, como estamos pronunciando pwsh?

pwsh
p.wush
p.woosh
puh.wush

Esperançosamente, algo melhor do que aqueles

@jonathanmedd Tenho usado pwish como wish com p .

Dado que _pwsh_ é uma sigla recursiva (semelhante a _GNU_) - Por favor, por que pwSH? - Eu sugiro "pweesh", como uma coelhinha fofa com um ceceio dizendo "por favor".

Brincadeiras à parte:

• Embora eu pessoalmente ache que escolher pwsh foi infeliz, presumo que nos acostumaremos em breve e não pensaremos nisso novamente.

• Quanto à pronúncia: pessoalmente não vejo necessidade de uma, visto que o nome completo é curto o suficiente e, para qualquer pessoa que viva no mundo do PowerShell, o mapeamento será óbvio. (Um exemplo do mundo Unix: zsh é aparentemente pronunciado zee shell ou zed shell , não como uma única sílaba).

P-Dub Shell ?

P Double U Shell ou P Double U S H é doloroso de se dizer. Mais sílabas do que PowerShell mas você provavelmente deseja distinguir PowerShell de pwsh . Assim como bash se distingue de Bourne-Again Shell .

você provavelmente gostaria de distinguir PowerShell de pwsh

Em termos de nomes completos oficiais, é _PowerShell Core_ vs. _Windows PowerShell_ - _PowerShell_ por si só pode se referir a qualquer edição.
Se não estiver claro no contexto, adicionar o qualificador apropriado irá eliminar a ambigüidade - e talvez não seja necessário com tanta frequência (por exemplo, em um contexto Unix puro).

A longo prazo, dado que PowerShell Core é a edição que roda em "todas" plataformas, eu não ficaria surpreso se _PowerShell_ se tornasse uma abreviação comum e informal para _PowerShell Core_ (o PowerShell "padrão"), com um qualificador - _Windows_ - usado apenas para se referir à edição do Windows.

Como um aparte:

Assim como o bash se distingue do Bourne-Again Shell.

bash _é_ o _Bourne-Again SHell_ - contrasta com seu predecessor, o _Bourne SHell_ ( sh ,
antes que POSIX padronizasse a linguagem).

@ mklement0 Estou falando sobre distinguir pwsh o binário de PowerShell a linguagem / shell. Não distinguindo diferentes implementações / plataformas do PowerShell. Assim como bash é usado para distinguir o binário de Bourn-Again SHell . Eles são intercambiáveis, sim, mas quando você precisa distinguir os 2, você precisa de uma maneira clara de pronunciar pwsh .

push: smile:

Então talvez:

p shell ou p w shell

@markekraus :

Ah, entendo, obrigado por esclarecer.

Se você quiser transmitir o nome _exato_ do binário, nenhuma pronúncia, exceto _petrar_ o nome irá ajudá-lo (isso só funcionaria com algo como posh ).

Portanto, referir-se ao _Binário / executável do PowerShell_ deve funcionar para todos aqueles que já conhecem e, para outros, você terá que explicá-lo de qualquer maneira.

Se você quiser transmitir o nome exato do binário, nenhuma pronúncia além de soletrar o nome o ajudará.

Teremos que concordar em discordar nisso 😃.

Eu entendo seu _desejo_ de que funcione - como faz com "bash" e "posh", por exemplo - mas como suas próprias lutas acima atestam, não funciona com "pwsh" - que, é justo supor, nós está preso com agora.

não funciona com "pwsh"

bem, não com essa atitude não! 😉 Tenho chamado de pwish e provavelmente continuarei a fazê-lo. Mas estou apenas criando um diálogo para ver se alguém chega com outra coisa. push é bom considerando a pronúncia de w em alguns idiomas. pwsh não completamente irredimível, IMO. talvez todos concordem em p w s h . mas é muito cedo para dizer "terminamos aqui" e considerar o assunto decidido, IMO.

:)

Você está certo.

Acho que estava me concentrando muito no aspecto de transmitir a _programação exata_ para alguém que ainda não estava familiarizado com o PowerShell, em vez de um nome curto estabelecido _por convenção_ para quem já sabe (que já sabe como mapear esse nome curto para pwsh ).

E quanto ao MSPosh. Mais curto do que PowerShell.exe e segue padrões, ao mesmo tempo que funciona como um nome divertido para The PowerShell Hero ?

@ 1RedOne, o herói / avatar do PowerShell sempre será PoSH-Chan em meu ❤️

Parece que a equipe PWSH estava correndo para mudar seu nome. :-)

Eu voto em pscmd.exe

ao digitar cmd no Windows, ele deve realmente aparecer! e na verdade está substituindo o cmd ...

se é uma questão de memória muscular, vamos resolver esse problema.

se for apenas para diversão encontrar um novo nome legal, então deveria ser pscore.exe, já que é isso que é.

apenas meus 2 centavos.

pwsh , o primeiro shell escrito por Wbject do mundo. Estou observando dois novos cmdlets continuando com esse padrão:

Get-Cwntent servers.txt | FwrEach-Wbject { 
    Invwke-Cwmmand -CwmputerName $_ -Scriptblwck { .. }
}

;)

-

Pronúncia de referência, que tal " powsh " dito como "bolsa" ou "sofá" com um "s" suave. (Pense nos impressionistas Sean Connery dizendo 'bolsa').

The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

Acho que essa mensagem de erro está relacionada a esse problema. Como faço para corrigir isso?

No que diz respeito à questão do nome real, eu voto em pwsh, já que Bash é o Bourne Again SHell.

Eu voto no PWSH. E eu pronunciaria isso como push.
Eu já vi muitos na comunidade usando chique, então essa seria minha segunda escolha, embora eu ache que MS pode estar tentando evitar chamá-lo de chique.

Eu voto em pwr !

@DaleMitchell como você obteve esse erro? Se você mesmo o construiu, recarregou build.psm1?

Já vi muitos na comunidade usando chique, embora

https://github.com/dahlbyk/posh-git por exemplo.

pwsh é pronunciado posh . @SaschaNaz POSH já existe como um shell, infelizmente

Perdi uma votação do @ PowerShell / powershell-Committee sobre como ela é pronunciada? :)

Achei que poderíamos pronunciar Microsoft Next Generation Command Line Interface Shell Experience 2017 , ou talvez apenas, você sabe, powershell .

Não vou usá-lo até que o Service Pack 2 da Shell Experience 2017 da Microsoft Next Generation Command Line Interface seja lançado ...

POSH já existe como um shell, infelizmente

Sim, vai ser MUITO confuso quando um usuário quer chique, tenta sudo apt install posh e então obtém um shell completamente diferente.

BTW, poh-sh ou pah-sh ? Certamente o último?

O nome do pacote ainda é PowerShell, nenhuma alteração aí:

sudo apt install powershell

Uma postagem rápida (opinativa) sobre o estado do debate:

• Quanto ao _nome do arquivo binário_: a decisão foi tomada e divulgada: pwsh é.

• Quanto à _pronúncia_:

  • Não há ninguém que possa transmitir a grafia exata do binário para o _não iniciado_ - nenhuma escolha a não ser soletrá-lo.

  • Para o _iniciado_, "PowerShell" é indiscutivelmente tudo o que é necessário, já que geralmente ficará claro no contexto se alguém está se referindo ao _produto_ ou ao _nome do arquivo do binary_ (preocupação de @markekraus ); se for o último, os iniciados irão traduzir isso automaticamente para pwsh em suas cabeças.
    Adicione "Core" e "Windows" para eliminar a ambigüidade, se necessário.

  • Desnecessário dizer que a busca apaixonada pelo apelido definitivo informal de uma sílaba continuará ...
    Uma vez que um ato de mapeamento mental em pwsh é necessário em qualquer evento, aqueles estabelecidos informalmente, como "Posh", também podem ter uso continuado.

Nos velhos tempos, quando usávamos o MKS Toolkit para suporte a script de plataforma cruzada, usávamos ksh.exe mas sempre o chamávamos de KornShell . Portanto, embora o binário seja pwsh , vou chamá-lo de PowerShell.

Acho que toda essa questão de "como se pronuncia o nome binário" poderia ter sido evitada se o nome binário fosse pwrsh mas o navio já navegou.

Nos "velhos tempos" (15 anos atrás contam?), Minha equipe chamava o binário de "kish" e "KornShell" era para uma discussão geral sobre o shell.

Exemplo:

"Digite ooser bin kish e pressione Enter. Agora você está no KornShell"

15 anos atrás contam?

É um pouco relativo à pessoa, eu acho. Minha experiência com KornShell começou há 24 anos. 15 anos atrás, minha filha era uma criança e isso não parece muito tempo atrás. Caramba - o tempo voa.

minha equipe chamou o binário "kish"

Não posso dizer que já ouvi isso ser pronunciado dessa forma. :-)

Não posso dizer que já ouvi isso ser pronunciado dessa forma. :-)

Sim. fora dessa equipe, sempre foi "ksh" ou "KornShell". Mas esse é o ponto: discutir como as pessoas vão pronunciar as letras "pwsh" (sem "PowerShell") e ver se há algum consenso. Não é uma discussão completamente séria e nada nunca vai ser uma pronúncia oficial, já que é uma palavra impronunciável (nenhum desrespeito pretendia equipe- push ). mas tem mérito que talvez um concorrente popular ganhe e comecemos a ouvi-lo nas apresentações.

Antes de trabalhar na Microsoft, eu era uma pessoa Unix e sempre chamei ksh Korn Shell e csh C Shell. Não me lembro de ninguém naquela época tentando pronunciá-los como palavras: P

Alguém poderia explicar concisamente por que uma alteração significativa como essa foi feita? Estou fora do circuito (claramente!) E estava conversando com @powerschill , e estamos um pouco surpresos, já que os links simbólicos são uma coisa.

Recapitulei a leitura sobre o processo de contribuição agora mesmo. No início, pensei que isso exigiria um RFC, mas posso ver como isso pode não se aplicar. A seguir, estou examinando a política sobre mudanças significativas (https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md). Vocês podem comentar em qual intervalo essa mudança caiu e assim por diante?

Não estou tentando mexer com algo que está claramente estabelecido, eu só quero ser capaz de me comunicar de forma eficaz com outros interessados ​​que não leem especificações e problemas. Obrigado!

@ halr9000 https://github.com/PowerShell/PowerShell/issues/4214#issuecomment -335989245

meu 2c. Esta é uma mudança importante. Muitos arquivos em lote existentes em cenários de produção existentes já usam o powershell.exe para iniciar scripts do PowerShell. Não sou contra o fornecimento de um comando curto adicional para iniciar o mesmo executável, mas remover o 'powershell' causará grandes estragos. Forneça uma maneira de usar ambos (alias ou qualquer outro)

@RudolfHenning Ao contrário das versões anteriores do Windows PowerShell, o PowerShell Core operará lado a lado com outra versão de si mesmo e com versões anteriores do Windows PowerShell. Deve haver uma maneira de chamar o núcleo do Windows PowerShell e do PowerShell a partir da linha de comando e dos scripts em lote sem ter que chamar o caminho completo do EXE pretendido ou sem arriscar a ordem do caminho resultando em powershell.exe chamando o errado versão.

Mesmo depois que o PowerShell Core 6.0 for lançado, continuará havendo a necessidade de usar o Windows PowerShell (5.1 e inferior) para muitas tarefas centradas no Windows, pois muitos dos módulos e scripts oficiais e da comunidade exigem acesso a objetos Full CLR indisponíveis no Core.

Além disso, qualquer pessoa que portar seus scripts de versões anteriores para 6.0 provavelmente precisará fazer ajustes, pois há muitas mudanças significativas entre 5.1 e 6.0. Como o código precisará ser alterado de qualquer maneira, o lote pode ser alternado para pwsh.exe de powershell.exe . Se eles não estiverem portando o PowerShell Core, nada será interrompido e os scripts continuarão sendo executados com powershell.exe usando o Windows PowerShell.

Obrigada pelo esclarecimento.
Como estou usando o Windows e alguns sistemas operacionais Linux, a compatibilidade de meus scripts às vezes é uma preocupação - sim, eu sei que as bibliotecas do PowerShell no Linux ainda são estritamente Beta. Investi bastante tempo e esforço na criação de scripts para minhas máquinas Linux.
Enfim, continue fazendo o bom trabalho!

O Powershell runner do TeamCity assume que o executável é denominado powershell . Como não há Powershell 5 no Linux para causar problemas de compatibilidade, o pacote Linux deve ter continuado a criar o link simbólico powershell . Isso foi uma quebra desnecessária.

O que, cheguei em abril? Vamos remover as vogais dos commandlets do PowerShell a seguir? Isso deve ser uma piada.

scripts mais antigos (docker) usando "powershell -command xxxx" não funcionam mais com a nova versão beta-9 ....

esperando a tempestade de merda

Existem muitos motivos para uma alteração significativa no local ou ponto de entrada "mais importante", mas encurtar o nome do comando em 6 bytes e torná-lo menos legível não é um deles ....
quantas vezes no passado decidimos usar um nome melhor / mais longo dentro de nosso código porque ler pode / deve ser mais fácil do que escrever ....

cust my 2cent
Saudações
Werner

Estou tentando entender a indignação e a falha.

As pessoas estão reclamando que o novo nome está quebrando as coisas, mas PowerShell Core ainda está em beta. IMO, se alguém está usando uma tecnologia beta no código de produção, está convidando o desastre (estou usando uma linguagem educada aqui). A natureza das versões alfa e beta é repleta de mudanças significativas. Não há ilusão de que isso não seja beta. beta é incorporado ao nome da versão: 6.0.0-beta.9 .

Essa mudança de nome não tem efeito no Windows PowerShell. Não deve interromper nada que você esteja fazendo no Windows. Se você estiver fazendo coisas no Linux, então você precisa reconhecer o fato de que está usando uma versão beta, em vez de culpar a versão beta por ser uma versão beta. Considere usar outra coisa até que a versão estável seja RTM, se você não puder lidar com as mudanças significativas entre as versões beta.

Eu entendo que as pessoas não gostam do nome. Você nem sempre consegue o que deseja. Eu pessoalmente odiava o PowerShell.exe porque é longo e difícil de digitar. pwsh tem pelo menos menos caracteres para eu bagunçar. Se você olhar o tópico de discussão, verá que várias opções foram discutidas, algumas delas muito piores (IMO) do que pwsh .

As pessoas interpretam isso erroneamente como uma tentativa estranha de se misturar com as crianças legais do Linux, quando um dos principais motivadores para um novo nome binário está relacionado ao Windows. Sim, um nome linux-y foi escolhido, mas adivinhe? PowerShell agora é um cidadão * nix também. Acho que é hora de as pessoas se acostumarem com esse fato. Um dos objetivos do Core é a portabilidade entre plataformas. Portanto, sim, as decisões podem e serão feitas com mais do que o Windows em mente.

então esse é o meu valor de 2 centavos.

Um dos objetivos do Core é a portabilidade multiplataforma

Uma parte da portabilidade de plataforma cruzada é que os mesmos comandos devem funcionar em ambas as plataformas se fizerem a mesma coisa. Antes dessa mudança, eu podia executar powershell independentemente do sistema operacional que estivesse usando e obter a coisa certa. Agora não posso mais fazer isso.

Criar software fácil de usar significa cuidar adequadamente de um milhão de pequenas coisas. Usar nomes estranhos e não intuitivos vai contra isso.

Eu poderia executar powershell independentemente do sistema operacional que estivesse usando e obter a coisa certa. Agora não posso mais fazer isso.

Não é preciso. Você poderia executar powershell no Windows e obter o Windows PowerShell, em seguida, executar powersehll no Linux e obter o PowerShell Core. Agora você pode executar pwsh no Windows ou Linux e obter o PowerShell Core. Portanto, AGORA estamos no estado que você deseja. onde, como antes, estávamos em um estado inconsistente.

Usar nomes estranhos e não intuitivos vai contra isso.

bem, está claro que não é universalmente apreciado, mas ... que alternativa você sugere? Vejo todos reclamando do nome, mas não há alternativas para o problema subjacente a que esse nome muda. Como eu disse, "Você nem sempre consegue o que deseja"

Não importa o nome escolhido, as pessoas ficariam infelizes.

@markekraus

• sabemos que é uma versão beta - alterações significativas estão ok!
• Sou um grande fã de melhorar o PS em * nix porque me ajuda a transferir meu conhecimento (PS) do Windows para * nix

Meu feedback foi sobre usabilidade e a preocupação de uma tempestade de merda que obriga a alguns renomeamentos e discussões intermináveis.

Você pode executar o PowerShell no Windows e obter o Windows PowerShell, em seguida, executar o Powersehll no Linux e obter o PowerShell Core. Agora você pode executar o pwsh no Windows ou Linux e obter o PowerShell Core. Portanto, AGORA estamos no estado que você deseja. onde, como antes, estávamos em um estado inconsistente.

Separar o Windows e o Core é realmente um motivo MELHOR para renomear e, em seguida, "Criar um nome mais curto"!

Eu sugiro fazer comunicações mais claras sobre isso (título do problema, notas de lançamento, etc.)
Eu li as primeiras 2-3 páginas desta edição e a discussão era apenas sobre o comprimento ....

outro feedback:
Nas últimas semanas, fiz muitas codificações com PS-Core no Docker e * nix
Eu gosto, mas precisa de algum polimento.
Ideia / Sugestão:
se o nome for alterado de Powershell para pwsh, por que não mudar a versão de 6.0 para 1.0 (mesma discussão como a transformação de ".Net 5.0" para "dotnet core 1.0
Basicamente, CORE é mais parecido com uma versão 1.0 do que uma versão 6, especialmente no * nix !!

Saudações
Werner

@WernerMairl Há uma discussão aberta sobre o uso de 1.0 em vez de 6.0.0 # 5165. Por favor, vá para esse tópico e leia e comente.

Além disso, como você o tem usado e se deparou com coisas que acha que precisam ser aprimoradas, verifique os problemas em aberto para ver se eles resolvem o que você encontrou. Se houver um problema aberto, vote ou comente e, se não, abra um novo problema para que possa ser corrigido. Vários de nós, membros da comunidade, estamos ativamente empenhados em consertar os problemas de prioridade mais baixa e a equipe da Microsoft tem feito um trabalho incrível trabalhando com os problemas de prioridade mais alta e mais difíceis. Além disso, nunca é tarde para se tornar um colaborador!

Sobre a descrição do problema e a comunicação da mudança, concordo que houve espaço para melhorias na comunicação dessa mudança e por que ela foi necessária. As funções de diferentes pessoas neste repo podem ser um pouco confusas, mas não faço parte da equipe do PowerShell, apenas um colaborador da comunidade com (essencialmente) privilégios de moderação do fórum. Não posso falar pela equipe do PowerShell, mas suspeito que eles próprios entendam esse fato.

Em sua defesa, este é meio difícil de comunicar. A maioria das reclamações parece resultar da falta de compreensão das semelhanças e diferenças entre o Windows PowerShell e o PowerShell Core. Para comunicar com eficácia essa mudança, eles também precisariam refazer o que foi explicado no artigo do blog de 14 de julho . Mesmo assim, as pessoas ainda têm dificuldade em navegar pelas semelhanças e diferenças. Acho que seria necessária uma longa descrição do motivo da mudança de nome que muitos ainda não leram. Suspeito que as tochas e os forcados teriam vindo de qualquer maneira.

Não é preciso. Você pode executar o PowerShell no Windows e obter o Windows PowerShell, em seguida, executar o Powersehll no Linux e obter o PowerShell Core. Agora você pode executar o pwsh no Windows ou Linux e obter o PowerShell Core. Portanto, AGORA estamos no estado que você deseja. onde, como antes, estávamos em um estado inconsistente.

Eu entendo o que você quer dizer, mas rebato que não é isso que eu quero. Há uma suposição oculta implícita em minha declaração: espero que o PowerShell e o PowerShell Core sejam completamente equivalentes, contanto que eu use recursos comuns. Até agora, isso ocorreu sem problemas em todos os meus casos de uso.

@sandersaares Acredito que sua experiência foi de sorte. Certamente não corresponde à minha experiência. Além disso, acredito que essa suposição seja perigosa. Esta é uma versão principal com uma tonelada de mudanças significativas documentadas com uma plataforma subjacente completamente diferente. Isso não será como as versões principais anteriores do PowerShell com quase 100% de compatibilidade com versões anteriores.

Vejo que algumas pessoas ainda fazem a falsa suposição de que a alteração do nome do executável foi principalmente para economizar na digitação. Posso ver como as pessoas podem ter ficado com essa impressão, já que esta edição original que foi usada para o PR começou com um título pedindo um nome mais curto.

Concordo que podemos melhorar nossa comunicação, pois não devemos esperar que todos leiam todos os comentários que o Comitê faz sobre as decisões. Particularmente em um controverso como este, onde o resumo da decisão é facilmente perdido.

Também parece que há um mal-entendido fundamental sobre o que é PowerShell Core 6, principalmente em relação ao Windows PowerShell. O Windows PowerShell 5.1 ainda é e será a versão embutida do PowerShell no Windows. Minha equipe também continua a apoiá-lo conforme necessário. Esperamos plenamente que os clientes continuem a confiar no Windows PowerShell pelo tempo que precisarem, o que pode muito bem ser pelo menos nos próximos 10 anos. Acho que só recentemente os downloads de WMF5.1 ultrapassaram os downloads de WMF4.0.

PowerShell Core 6 é a próxima evolução do PowerShell, onde não é apenas plataforma cruzada, mas também Open Source. Como @markekraus observou, é uma alteração de versão principal que nos permitiu mais flexibilidade na aceitação de alterações significativas que nunca consideraríamos para o Windows PowerShell. Também observou que o PowerShell Core 6 foi explicitamente projetado para funcionar lado a lado (não apenas com o Windows PowerShell, mas com outras versões do PSCore6). Não deve haver ambiguidade em relação ao que você obtém no Windows ao digitar powershell . Vou apenas observar aqui que a discussão 6.0 vs 1.0 já aconteceu muito tempo antes de abrirmos o capital e é improvável que seja reaberta.

@ SteveL-MSFT, um post no blog sobre a mudança de nome seria bom. Ele pode cobrir o principal motivo da mudança de nome com um exemplo claro do problema no Windows. Também seria bom explicar por que posh e psh não foram incluídos também.

Talvez configure "powershell" como um apelido para pwsh durante a descompactação + instalação. Isso apenas interrompeu uma compilação na qual eu estava trabalhando por alguns dias, até que rastreei esse problema.

Editar: no linux

@markekraus tem uma ótima postagem no blog que captura o quê e por quê:

https://get-powershellblog.blogspot.sg/2017/10/why-pwsh-was-chosen-for-powershell-core.html

Hoje eu vi o primeiro uso de pwsh no SO aqui, embora eu duvide que a pessoa saiba sobre este tópico ...

Podemos obter uma decisão oficial sobre a pronúncia de pwsh ? A especificação PNG inclui uma pronúncia em sua Seção 1. Também pode fornecer uma para PowerShell; não quero outra situação SCSI "scuzzy" / "sexy".

Parece "bosta" para mim.

@apjanke a pronúncia geralmente aceita de pwsh é posh

Funciona para mim. Obrigado pela confirmação oficial!

Quanto às pronúncias alternativas: ^[1]

• _Pish Posh! _

• _Poppyposh! _

• _The Shell anteriormente conhecido como PowerShell_ (_TSFKAP_ em georgiano )

• _A Shell que não ousa falar seu nome (porque o nome de seu executável é impronunciável) _ (preferido pelos falantes de galês ).

^{[1] [Paródia.}