Isso torna o uso de rm , ls , etc. uma porcaria, uma vez que o globbing não é realizado:

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

Blah.

A sincronização de usabilidade geralmente concorda que a experiência interativa é uma droga sem os apelidos. O que não concordamos é quais alternativas devem ser oferecidas aos usuários que desejam usar os binários nativos por padrão. Algumas opções que foram lançadas incluem:

• Uma variável de ambiente para desligar todos os aliases que colidem com binários * nix
• Um único caractere (como ^ ) que cai automaticamente no PATH nativo
• Diga às pessoas que precisam bash -c (muitos disseram que são muitos caracteres para serem utilizáveis)
• Diga às pessoas que elas têm que fornecer o caminho completo (essa experiência tecnicamente já funciona, mas é muito ruim)
• Sugestão lateral: Aproveite o "subsistema de sugestão" para dizer às pessoas que elas podem querer usar o comando nativo se usarem conjuntos de parâmetros que correspondem a padrões em relação aos binários * nix nativos. Isso ainda pode funcionar apenas quando o comando falha ( rm -e , por exemplo, não falharia).

Acho que isso é algo que queremos descobrir mais cedo ou mais tarde, então mudei para a v0.5.0. Na minha opinião, uma configuração do PowerShell para alternar os modos é a melhor primeira etapa.

@andschwa e o padrão seriam ....?

@vors minha opinião

Eventualmente, vamos querer um guia de "primeiros passos" de inicialização do PowerShell de qualquer maneira, e afirmaríamos que essa é uma configuração disponível.

@BrucePay alguma atualização sobre isso?

A sincronização de usabilidade hoje reiterou que os aliases devem voltar. (Canalizar para sort é outro ponto de dados em ter uma experiência PS totalmente quebrada.)

Deixando Bruce como cessionário para determinar o melhor caminho a seguir com as atenuações acima. @andschwa : provavelmente precisamos de outra pessoa designada para fazer o trabalho de colocar os aliases de volta.

Eu só tive uma conversa com @jpsnover e ele é muito claro que não estamos colocando aliases de volta. Devemos criar o arquivo da caixa de entrada aliases.ps1 e promover seu dot sourcing.

Provavelmente vale a pena apontar que ls no bash normalmente não é simplesmente ls , é um apelido com alguns argumentos padrão, com talvez o mais notável para saída usando cores.

Os aliases do PowerShell não funcionam como aliases no Linux, então precisaríamos definir ls como uma função ou aprimorar nossos aliases para funcionarem mais como aliases de bash.

Também pode valer a pena gastar algum tempo analisando módulos na galeria para ver quantos não funcionariam como estão com os apelidos removidos - sort é especialmente preocupante.

Os aliases não estão disponíveis hoje e devemos ter certeza de que, em 17 de agosto, teremos uma discussão saudável sobre os prós / contras das situações de alias para as pessoas participarem.

Parece que temos uma história encerrando o problema.

Meu 2p sobre isso - uma nova variável de configurações do PowerShell semelhante a $ PSModuleAutoLoadingPreference que foi introduzida no PSv3 permitiria que isso fosse controlado pelo usuário final em seus perfis (também poderia reunir um exemplo simples que mostra alguns comandos em execução com e sem o PS Aliases como um bom

Nome sugestivo $ PSUsePowerShellAliases e se não for explicitamente definido como verdadeiro (dentro do perfil ou interativamente), os aliases * nix padrão seriam usados ​​no lugar.
Eu acredito que isso provavelmente também daria uma UX melhor para aqueles que agora podem decidir testar a água com PowerShell que não teriam feito antes, pois não está tirando o que eles sabem, mas permite que aqueles de nós que conhecem a maneira PS a habilidade para fazer isso também.

não tirando o que eles sabem

Absolutamente. Se for necessário haver um compromisso, ele deve ser a favor dos usuários do Linux Bash, ou seja, novos usuários do PowerShell em potencial. Os fiéis do PowerShell existentes podem recriar seus aliases * nix com bastante facilidade ou, melhor ainda, livrar-se desses aliases.

Na verdade, agora que temos o PowerShell no Linux, gostaria de ver os aliases * nix integrados removidos de todas as versões do sistema operacional do PowerShell Core - se ainda não foram. Isso deixaria aliases internos que correspondem aos comandos internos do PowerShell e não tentam "enganar" você.

Sou fã de remover os apelidos comuns do ps no Linux por padrão - não sou fã de "consertar" isso no Windows, como sugere Keith. Meu argumento para isso é que, se você conquistar um usuário do Linux para o PowerShell e ele decidir experimentá-lo também no Windows, não terá os aliases comuns.

Isso poderia ser adicionado ao PSReadline, a capacidade de habilitar Aliases do Linux ou não? Para mim, é simples consertar meu código que usa nomes curtos para funções. Ainda assim, sempre irei digitar LS primeiro e esperar que funcione como o alias do PowerShell LS para Get-ChildItem .

Sinta-se à vontade para usar este problema para expressar sua opinião sobre como deve ser o comportamento do PowerShell.

Acho que o que @kilasuit , @rkeithhill e @ 1RedOne tocaram parece ser a melhor solução - desabilitá-lo por padrão no Linux e macOS, mas ao mesmo tempo, torna mais fácil para nós habilitá-lo no console ou no nossos scripts.

Os scripts existentes podem ser atualizados para verificar essa variável e desabilitar ou habilitar a opção ali mesmo, e é melhor do que derramar um monte de código para procurar nomes curtos que não se comportem como o esperado.

Fora do tópico - além do entusiasmo com o fato de o PowerShell estar disponível em outras plataformas! 😄

em relação ao PSReadLine então @lzybkr deve ser capaz de sugerir se essa é uma possibilidade, embora eu prefira como uma variável PS do que um requisito para PSReadLine, pois há aqueles como @juneb que não usam PSReadline de todo

Eu certamente poderia publicar um exemplo de PSReadline para substituir aliases específicos pelo cmdlet PowerShell, seria baseado neste exemplo: https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354

Dito isso, não acho que seja uma solução real.

O maior problema em minha mente é o conflito entre portabilidade do script e familiaridade. Fornecemos orientações de que os scripts não devem usar aliases, mas ainda é uma prática comum. Alguns apelidos podem ser mais problemáticos do que outros, por exemplo, sort pode ser usado mais do que ps ou ls em scripts.

Certamente discutimos algumas opções, como fornecer um módulo que você acabou de importar para obter esses aliases de volta. Mas ainda não decidimos nada e estamos esperando por mais comentários.

Substituir comandos do PowerShell por executáveis ​​nativos sem suporte a globbing definitivamente não ajudará a convencer os caras do bash a usar o PowerShell.

Então, pessoal, talvez seja melhor simplesmente adicionar suporte a globbing para executáveis ​​nativos? Isso resolverá todos os problemas e tornará o PowerShell mais utilizável para todos, certo? Link # 954.

Como um usuário * nix que quase nunca tocou nas janelas, gostaria de votar fortemente por deixar os aliases. Muitos anos de memória muscular me ensinaram a usar ls , rm , etc. Eu não quero ter que reaprender minha memória muscular (então reaprendê-la sempre que terminar no bash) para obter a experiência nativa do PowerShell.

Corrija-me se eu estiver errado aqui, mas isso é diferente para dir no Windows? Em PS no Windows, dir não é dir.exe . É Get-ChildItem . Em * nix, por que ls deveria ser /bin/ls vez de Get-ChildItem ?

@Gaelan Entendi , mas considere que não existe um arquivo dir.exe no Windows. dir é um comando interno do processador de comandos cmd , semelhante a bash builtin. Talvez seja esse o (um) motivo porque o PowerShell não foi projetado para chamar esse comando dir.exe externo diretamente.

@Gaelan , @ForNeVeR : Embora cmd-built-ins nunca

Em geral, não acho que _is_ uma maneira segura de manter aliases e _não_ quebrando coisas porque teoricamente cada alias (exceto talvez aqueles que não podem existir no sistema de arquivos, como ? ) poderia ocultar um executável nativo que não pode mais ser chamado (pelo menos não por seu nome de base).

PS> gal|?{gcm "$_.exe" -ea 0}

CommandType     Name
-----------     ----
Alias           fc -> Format-Custom
Alias           sc -> Set-Content
Alias           sort -> Sort-Object
Alias           where -> Where-Object
Alias           write -> Write-Output

Portanto, a única rota _segura_ seria não ter nenhum apelido, o que meio que anula o propósito. E, sem dúvida, os aliases padrão são, acima de tudo, convenientes. Não tenho uma boa resposta aqui, na verdade.

Eu pessoalmente preferiria que os aliases permanecessem. Eles geralmente existem para tornar a navegação e o uso geral do shell mais rápidos e confortáveis. Removê-los degradará a experiência de uso do PowerShell.

Eu apoio a ideia de possivelmente adicionar uma maneira de indicar que você está chamando o binário integrado do Linux. Talvez até como preferência de perfil?

Se você olhar a história aqui, sugeri o que acho ser a melhor solução de uma perspectiva de UX para aliases que mapeiam para comandos não-Windows equivalentes

Este é um problema antigo do PowerShell. Eu reclamo que ele não tem um comando comparável ao dir do cmd ou mesmo ls . A resposta, todas as vezes, é "mas há um alias!".

Os apelidos não são e nunca foram uma solução para esse problema. Os aliases dir e ls não fornecem a funcionalidade que dir e ls fornecem. O mesmo é verdadeiro para os aliases wget e curl .

Toda a abordagem dos aliases precisa ser repensada, e isso significará alterações significativas.

Por que os aliases definidos pelo sistema não podem ser apenas cidadãos de segunda classe dos binários no PATH?

Eu diria para remover todos os aliases * nix no Linux, versões do OS X até que você descubra o que fazer.

Edit: Obrigado por esclarecer que isso já foi feito, desculpe a interrupção.

@okket que já foi feito. Estamos discutindo se algo precisa ser mudado.

Parece-me que deveríamos apenas colocar todos os apelidos nos arquivos que as pessoas podem obter em seus perfis e, em seguida, fornecer um perfil específico do sistema padrão ...

bash-aliases.ps1
dos-aliases.ps1
initial-aliases.ps1

Isso serve para lembrar às pessoas que nem todos têm os mesmos nomes curtos.

Não vamos esquecer (@sleepypikachu) que os aliases do PowerShell não _fazem_ nada, exceto renomear o comando e substituir a ordem de resolução do comando. A funcionalidade alias Bash requer _functions_ no PowerShell.

@Gaelan sua memória muscular permite que você use o apelido, mas você ficaria frustrado com os parâmetros e o comportamento não funcionando da mesma forma que o comando real?

Esse é o verdadeiro problema aqui e @DrPizza está no local. Um ótimo exemplo é, _dir / s_. Esse comando falha no PowerShell, então você deve alterá-lo para dir -recurse.

Portanto, existem realmente três questões relacionadas aqui:

1. Nem todos os parâmetros têm aliases
2. Nem todos os parâmetros ou comportamentos nativos são mapeados no PowerShell CmdLet.
3. Precisa de uma maneira de executar o comando nativo se o alias existir

Não acho que o número 1 seja um problema tão ruim e tornaria as coisas piores se tivessem um alias. Dir -recurse é um parâmetro mais legível do que dir / s de qualquer maneira. Além disso, com o cross-plat, ele torna os scripts inconsistentes ao tentar mover do Windows para o Linux e vice-versa.

2 e 3 são os mais importantes. Eu nunca usei o curl, mas sei que encontrei limitações com Invoke-WebRequest que eu esperava que o curl fosse capaz de fazer. (Não se lembre de cima da cabeça).

A curto prazo, acho que você precisa de uma opção de configuração e também de uma maneira de chamar o comando nativo se o alias estiver ativado.

Padrão, deixe-o ativado. Este é o PowerShell .... no Linux. Ele deve se comportar como PowerShell para que eles possam aprender quais CmdLets usar. Meu colega de trabalho com experiência em Linux e Perl achou muito mais fácil descobrir os cmds de que precisava para fazer um script funcionar. Acho que foi grep, ls e man que foi a chave para ele. Usar man deve ajudá-los a descobrir como usar o cmd corretamente.

A longo prazo, adicione cobertura aos cmdlets nativos para ter todos os parâmetros e recursos dos comandos nativos. Isso aprimora o PowerShell para Windows e Linux, oferecendo opções mais poderosas. Alguns dos comportamentos provavelmente precisarão ser convertidos em vários CmdLets e usar objetos e pipelines, mas isso é ótimo! Se não fizesse isso, qual seria o objetivo do PowerShell?

Minha opinião é manter como está. Nenhum alias no PowerShell (exceto select e etc., eles são necessários), alias no Windows PowerShell.

Fornecer uma opção é melhor, mas fornecer todos os aliases como opções é ... bem, não impossível.

IMHO ter ls alias para dir faz sentido, já que eu poderia facilmente usar Where-Object para filtrar arquivos. Sou usuário Linux há anos e digitar dir não é tão natural quanto usar ls.

Parece-me que a consistência é importante. Não sou contra a remoção de aliases de outras plataformas, mas ter uma interface que se comporta de forma diferente dependendo do sistema operacional me incomoda. Um dos principais pontos de ter o PS rodando no * nix é que ele é uma interface para gerenciar tudo. Se os aliases forem removidos do PowerShell nas plataformas recentemente suportadas, acho que algumas considerações devem ser feitas se eles devem ser removidos no Windows também.

Não, eu apoio fortemente que o PS forneça aliases por padrão, mas o real abaixo deve ter exatamente a mesma funcionalidade (e talvez compatibilidade de parâmetros) com os binários nativos originais, exceto para suporte de digitação.
PowerShell sem tipos é inútil.

Usar os binários do sistema subjacente e adotar a filosofia de ferramentas Unix promoverá a adoção. Como uma pessoa que faz devops em lojas de unix, fiquei agradavelmente surpreso ao descobrir que os binários normais do unix estavam funcionando de alguma forma nesta implementação. Em relação ao * problema de caractere, acho que a maioria das pessoas no lado * nix se sentiria confortável em usar um caractere de escape na frente do * ao indicar * nix shell glob em oposição a qualquer que seja seu comportamento atual no PowerShell. Provavelmente seria uma solução aceitável para | como um tubo que produz um objeto em vez de um fluxo de octetos passando entre os arquivos, vai contra os padrões publicados e atrapalha a adoção. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis , observe: ninguém vai remover tipos do PowerShell ; gci e Get-ChildItem permanecem iguais no Windows PowerShell e no Linux PowerShell. Aqui, estamos apenas falando sobre se um alias integrado como ls -> Get-ChildItem deve existir no Linux ou não. Seus scripts não devem chamar ls ou gci qualquer maneira se você pretende chamar Get-ChildItem (porque usar apelidos em scripts não é recomendado e nunca foi recomendado). ls e gci são apenas apelidos de conveniência para uso de linha de comando e _pode_ confundir o usuário do Linux se ls repentinamente receber o apelido de Get-ChildItem e não o dele comando nativo favorito; ficará ainda mais confuso se ele não tiver uma maneira concisa de chamar esse comando diretamente.

Eu sou para usar o comando para habilitar o alias no PowerShell.
Mantenha todos os apelidos e desative-os lentamente no Windows PowerShell.

Eu acho que usar o comando como

Enable-Alias Unix
Enable-Alias dos

Ativar o alias tem as seguintes vantagens

1. Isso resolve o problema para quem quer usar o curl nativo
2. Isso desencoraja as pessoas a usarem alias em scripts (o que atrapalha a legibilidade do script).
3. Também é muito fácil para as pessoas que amam esses alias habilitá-los
4. e mal compromete qualquer desempenho.

@ForNeVeR Eu uso ls como gci o dia todo porque é uma letra a menos ...
No entanto, a introdução dessa mudança (remover aliases unix-y e dos-y) é definitivamente uma mudança importante (não é como curl ). Uma solução “perfeita” pode ser implementar esses comandos para um aprimoramento digitado de ferramentas existentes.
Para scripts, talvez ... uma instrução using ?

@ForNeVeR Acho que você entendeu mal @ be5invis . Ele é um forte defensor do PowerShell. Eu acho que o que ele quer dizer com "PowerShell sem tipo é inútil" é que as pessoas não deveriam usar cachos nativos em PowerShell.

@ be5invis Além disso, acho que sua ideia de compatibilidade do curl nativo é de longo alcance. A gramática do PowerShell não é compatível com a gramática Unix padrão, por exemplo, você pode fazer rm -rf no Unix, mas no PowerShell você deve fazer rm -r -fo .
Portanto, você nunca alcançará a compatibilidade de parâmetros, não importa o quê.

@chantisnake Então por que não adicionar um parâmetro chamado “rf”, que é igual a -recurse -force ?

@ be5invis Isso vai contra o modo como os parâmetros funcionam no PowerShell. Eles são ortogonais e, se não forem, existem diferentes conjuntos de parâmetros. Eles também têm apenas nomes longos e, em vez de nomes curtos, podem ser abreviados individualmente, desde que não sejam ambíguos. No seu caso, você também precisa adicionar um alias a esse parâmetro, fr . Além disso, de repente -Recurse não poderia mais ser encurtado para -r mas teria que ser -re para não entrar em conflito com o parâmetro -rf proposto.

Você poderia fazer a mesma pergunta do outro lado: Por que não especificar os dois parâmetros separadamente? Você está disposto a ir contra os princípios e convenções de código do PowerShell de uma maneira bastante ampla, apenas para continuar fingindo que ainda está trabalhando com as mesmas ferramentas Unix, mesmo que não esteja. No entanto, as convenções de parâmetros GNU com seus nomes curtos e longos dificilmente são universais e muitas ferramentas bem estabelecidas vão contra eles, por exemplo, tar ou find . No entanto, você não está em pé de guerra com seus rastreadores de bug para mudá-los. Embora uma parte central do Unix sempre tenha sido a de que há um bilhão de programas utilitários diferentes, cada um funcionando de maneiras ligeiramente diferentes, de repente ter outro deles (reconhecidamente fazendo um pouco mais e tentando incluir muitos outros utilitários em si) é tão desconcertante e problemático que precisa ser mudado? Acho que não.

Lembre-se: o shell de sua máquina é seu. Assim como as pessoas alias rm a rm -i para seu próprio conforto, não há nada que impeça você de remover o alias rm e ter uma função envolvendo Remove-Item chamada rm com um parâmetro -rf .

Mas tentar mudar o PowerShell em sua totalidade para replicar completamente cada ferramenta Unix é um tanto equivocado.

A funcionalidade e a saída de ls foram bem definidas por muitos anos. O comando ls produz um fluxo de octetos em um formato bem conhecido. O comando ls não produz objetos DirectoryInfo e FileInfo. Ter ls gerando algo diferente é no mínimo confuso e possivelmente um pouco enganoso.

Quando o usuário estiver pronto para ter os benefícios dos objetos no pipeline, ele aprenderá sobre Get-ChildItem e gci. Se o usuário não quiser ter os benefícios de, ou lidar com, objetos no pipeline, o usuário pode se sair melhor usando bash, ksh, csh, sh, etc.

O mesmo pode ser dito do comando DIR no Windows.

Deixe * nix ser * nix e tornar o Powershell o melhor possível.

@Liturgist

Quando o usuário estiver pronto para ter os benefícios dos objetos no pipeline, ele aprenderá sobre Get-ChildItem e gci. Se o usuário não quiser ter os benefícios de, ou lidar com, objetos no pipeline, o usuário pode se sair melhor usando bash, ksh, csh, sh, etc.

Isso contradiz seu ponto. Se as pessoas estão usando o Powershell, provavelmente desejam objetos no pipeline. Não devemos reaprender os comandos básicos para tirar vantagem disso.

Concordo com @Gaelan.
Se alguém não quiser objetos, pode simplesmente mudar para bash ou zsh.
Eles querem os benefícios dos objetos e aliasing coisas como ls para uma versão compatível, mas digitada, vai dar-lhes exatamente o que desejam.

@Gaelan e @ be5invis , entendo o desejo de limitar a quantidade de alterações que um usuário deve fazer para usar o Powershell. Meus dedos parecem digitar ls antes mesmo de meu cérebro enviar um sinal para eles.

O problema é que esses comandos básicos existentes não produzem objetos. A mudança real a ser feita não é de ls para gci . A maior mudança é do pensamento feito para processar linhas de texto para pensar sobre as propriedades e quais métodos podem ser aplicados a um objeto.

É direito de todo usuário criar os apelidos que desejar. Eu concordaria que poderia ser mais fácil para o usuário fazer isso adicionando um método e uma propriedade a $ Host (System.Management.Automation.Internal.Host.InternalHost) para habilitar ou desabilitar a substituição do comando nativo. Já vi outros, mas há uma ferramenta de configuração de perfil de GUI incluída no Powershell?

Se alguém não quiser objetos, pode simplesmente mudar para bash ou zsh.

Por que o PowerShell não pode fornecer um "acesso fácil" para pessoas que usam o bash há anos e então decidem mergulhar nas águas do PowerShell? Deixe-os começar com o que sabem e começar a graduar os recursos do PowerShell (como objetos que emitem comandos e objetos no pipeline) à medida que se sentem mais confortáveis ​​com o PowerShell.

Eu não posso te dizer quantas vezes eu tive que usar a linha "_PowerShell é um shell . Ele executará seus utilitários nativos favoritos muito bem_" para fazer as pessoas ultrapassarem a noção de que eles só poderiam usar o PowerShell com aqueles comandos estranhos e fazer com que eles realmente experimentem o PowerShell. O PowerShell precisa respeitar e trabalhar com utilitários nativos populares da melhor maneira possível - ponto final. Afinal, essa é uma das principais tarefas de uma "concha".

@rkeithhill Então deixe-me esclarecer: para os usuários que desejam usar o Powershell, eles desejam tipos, certo? No entanto, suas ferramentas nativas, como /bin/ls , não podem se comunicar com tipos. Portanto, alternar para um shell digitado, mas sem utils digitados, a mudança não faz sentido.

Portanto, usuários típicos do Unix podem querer digitar o comando idêntico, mas obter o resultado digitado diretamente. Portanto, há duas opções:

1. Crie um protocolo IPC digitado e diga a Linus para atualizar suas ferramentas - Não, eles não farão, porque é proposto por seu INIMIGO , o SENHOR MAL , o destruidor do mundo livre ! Eles vão nos “abraçar, estender e extinguir”! ou...
2. Alias ls para um embutido com parâmetros compatíveis.

Para os usuários que desejam usar o Powershell, eles desejam tipos, certo?

Eventualmente, eles provavelmente vão. Dito isso, eu trabalho com vários desenvolvedores que comecei no PowerShell meramente vendendo-os para usá-lo com Git e Posh-Git (algo que o CMD não pode fornecer). Eles raramente canalizam alguma coisa neste ponto, mas espero que cheguem lá. Esse ponto é, o utilitário git.exe se comporta no PowerShell da mesma forma que se comporta no CMD. Transição fácil.

Para mim, ls (como ps, grep, sed, awk, gcc, curl, etc) é apenas outro utilitário nativo que qualquer "shell" deve ser capaz de executar. Agora, se alguém está pronto e deseja que o objeto emita o comando para listar o conteúdo do container, pode usar Get-ChildItem ou seu apelido gci . Se eles estão inclinados a nunca usar o utilitário nativo ls , eles podem criar um ls alias para Get-ChildItem em seu perfil.

BTW, não acho que tentar tornar o parâmetro Get-ChildItem compatível com ls seja viável. Você ficará travado muito rapidamente com os parâmetros do PowerShell que não diferenciam maiúsculas de minúsculas, por exemplo -c / -C, -d / -D, -i / -I. E o PowerShell não oferece suporte à combinação de parâmetros, por exemplo, ls -rt. É um alcance e viola o princípio Monad do PowerShell. Uma tarefa como a classificação seria realizada por um cmdlet separado (Sort-Object) e não pelo próprio Get-ChildItem.

@rkeithhill Eu não vou fazer Get-ChildItem sendo compatível com ls . Estou propondo outro cmdlet, pode ser chamado de UnixCompatibles-ls como seu nome completo e tem um analisador de comando separado que aceita o sabor GNU getopt, em vez de PowerShell.

@ be5invis Nesse ponto, a opção mais fácil não é uma função separada que executa ls , passando todos os seus argumentos, analisa a saída e cria objetos a partir deles? Um analisador de comando completamente separado (junto com metadados de comando completamente separados, formatando para Get-Help , ...) é um pouco exagerado (além de replicar muito do funcionamento interno do PowerShell de uma maneira incompatível.

Sempre haverá dois mundos separados aqui, um nativo, um digitado. O PowerShell já atende a ambos, sendo capaz de executar programas nativos e cmdlets. Eu, pessoalmente, não vejo nenhum benefício (apenas um grande empreendimento no esforço de desenvolvimento) em tentar adicionar uma camada acima dos comandos nativos que replica seus metadados de parâmetro dentro do PowerShell. Além disso, o que você faria sobre tar , ou find (e muitos outros programas), os quais AFAIK não aderem às convenções GNU. Implementar ainda _outro_ analisador de comandos, junto com funções de invólucro para chamá-los? Observe também que para um analisador de comando funcionar, os argumentos do programa nativo devem ser analisados ​​no PowerShell e não devem entrar em conflito com a linguagem. Algo que pode ser difícil com coisas estranhas como [ .

@ygra Também está tudo bem.

Para os usuários que desejam usar o Powershell, eles desejam tipos, certo?

@ be5invis , talvez seja aqui que ocorre um pouco de desconexão. Não, eles não querem tipos. O usuário deseja realizar seu trabalho ou diversão. O usuário sabe que ls produz um fluxo de texto.

UnixCompatibles um verbo? Isso mudaria o script $ PROFILE do usuário permanentemente ou apenas para esta sessão? Eu não gostaria que Get-ChildItem fosse compatível com ls. Seja ls ls e faça o que ls faz. Parece que isso daria ao usuário a opção de substituir ls por Get-ChildItem . Isso é bom. Não tenho certeza se quero isso, mas para aqueles que querem, tudo bem.

@Liturgist Acho que @ be5invis significa que se as pessoas se deram ao trabalho de mudar para o Powershell (em vez de ficar com o Bash), é porque querem algo que o Powershell oferece. Se as pessoas quisessem um fluxo de texto de ls , (no Linux ou macOS), elas nunca teriam se incomodado com o Powershell.

@Gaelan Então, não devo usar o PowerShell se precisar usar gcc ou git? O que há de errado em permitir que as pessoas decidam se desejam texto (ls) ou objetos (gci)? Existem mais razões para usar o PowerShell do que apenas sua natureza OO - poderoso como é. Prefiro usar o PowerShell apenas para suas declarações de fluxo de controle como C / C # (vs if / fi e switch case / esac) e seu sistema de tipo apropriado (onde os números são números e não strings).

@rkeithhill

Portanto, não devo usar o PowerShell se precisar usar gcc ou git?

Em um sistema * nix, se os usuários quisessem apenas usar o shell para gcc ou git, eles não se incomodariam com o PowerShell, porque o shell que acompanha o sistema operacional faz isso perfeitamente bem.

Heck, eu prefiro usar o PowerShell apenas para suas declarações de fluxo de controle como C / C # (vs if / fi e switch case / esac)

Talvez se alguém já estivesse usando o PowerShell preferisse por causa disso, mas duvido que alguém instalaria o PS só para isso.

seu sistema de tipo apropriado (onde os números são números e não strings)

/bin/ls também não funciona com o sistema de tipos: se eu executar ls -l , obterei os tamanhos dos arquivos como uma string em vez de um número PS adequado.

Acho que os motivos pelos quais um novo usuário mudaria para PS no * nix giram em torno do OO e do sistema de tipos. Devemos tornar o mais fácil possível para novos usuários começarem a usar o PS - se eu visse algo sobre o PS, tentasse dar uma olhada, apenas para descobrir que precisava reaprender tudo sobre a linha de comando para usá-lo, provavelmente iria seria muito menos provável que me incomodasse em aprendê-lo do que se pudesse iniciar o PS, digitar ls e ver imediatamente o sistema de tipos em ação. Sim, eu poderia usar aliases, mas se estou apenas testando o PS em alguns minutos livres, é improvável que queira fazer muitas configurações antes de começar a brincar.

Em um sistema * nix, se os usuários quisessem apenas usar o shell para gcc ou git, eles não se incomodariam com o PowerShell, porque o shell que acompanha o sistema operacional faz isso perfeitamente bem.

Talvez se alguém já estivesse usando o PowerShell preferisse por causa disso, mas duvido que alguém instalaria o PS só para isso.

Desculpe, mas discordo totalmente. Como um usuário Linux, eu quero usar o PowerShell em vez de concha que veio com o meu OS. Para tudo. Porque é incrível, você sabe :)

Caramba, estou até empacotando o PowerShell para NixOS agora, apenas para usá-lo para tudo.

Por favor, considere que nossos usuários-alvo não são apenas usuários Unix nativos que acidentalmente usam Windows + PowerShell, mas também usuários do Windows que usam Unix + PowerShell acidentalmente;)

Um único caractere (como ^) que cai automaticamente no PATH nativo

Eu também preferiria manter os aliases compatíveis entre o sistema operacional sempre que eles forem válidos nessas plataformas e usar um caractere de escape (como ^ls ) para obter um acesso implícito aos comandos nativos, conforme sugerido por @joeyaiello
Não estou familiarizado com toda a filosofia do PowersShell, mas o que poderia haver de errado com essa abordagem?

Na verdade, mais um ponto para usar um escape de caractere único: o bash já faz isso. https://twitter.com/climagic/status/806536501232340992

\ls ignora todos os aliases.

A resposta aos aliases foi resolvida com a ativação do WSL (subsistema do Windows para Linux)? Isso fornecerá comandos nativos sed, awk, ls, etc. em um shell bash.

Embora ainda seja um código beta para o Windows 10, com certeza ele virá e estará disponível no Server 2016 e 2012.

@Liturgist Atualmente, o WSL é um ambiente muito separado do PowerShell. Os comandos não podem ser chamados de uma sessão do PowerShell. Além disso, isso provavelmente seria considerado uma regressão por muitos usuários atuais do Windows PowerShell, pois muitos scripts seriam interrompidos se recebessem a saída de, digamos, GNU ls vez de ls -> Get-ChildItem . Embora o uso de aliases nunca tenha sido recomendado em scripts, o fato é que eles têm sido usados ​​e quebras causariam dificuldades para muitas pessoas.

@Liturgist : @bgshacklett está bem aqui. O problema não é que algo aconteça quando você digita ls , a questão é quais parâmetros você espera ao usar isso e se a saída emitida pode ser consumida de forma orientada a objetos por outros cmdlets do PowerShell (ou seja, ls | Where-Object Name -like *foo* não funcionará se você estiver usando o WSL ls ).

O problema original com aliases conflitantes com cmds nativos foi resolvido. Se houver necessidade de adicionar novamente aliases populares do Windows PowerShell, isso deve ser um problema separado.

Https://github.com/PowerShell/PowerShell/issues/3610 aberto para capturar o problema secundário