Powershell: Podemos usar | na próxima linha como um caractere de continuação?

Em um script - sim, mas isso quebraria a capacidade de usar o botão direito do mouse ou Alt + e, p colar no console, porque depois de inserir, você teria uma linha de comando completa.

Discussão relacionada # 2819

Vejo UX ruim para a sessão interativa: após o primeiro NewLine parser vai esperar o próximo NewLine ou pular espaços até | ou NewLine - isso confundirá o usuário .

Para o script, é uma solicitação para excluir um caractere de continuação `(crase) a tempo, pois sempre podemos digitar:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

O analisador já faz isso em outros lugares.

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

@lzybkr obviamente ter o analisador capaz de entender isso não significa que as pessoas _devem_ escrever várias linhas dessa maneira - muitas pessoas adotaram o estilo stroustrup como acima, ou até mesmo "travar em sua própria linha" e outras coisas de estilo que quebram ao serem coladas (especialmente porque o PSReadLine mexeu com o botão direito do mouse e fez o Ctrl + V funcionar). Isso não deve fazer nenhuma diferença.

@iSazonov interativamente, se você apertar enter, não vai esperar, só vai executá-lo. Exatamente como agora com o else acima. Você pode pressionar shift + enter para digitá-lo no console (quando você tiver PSReadLine).

PSReadline não mexe com o clique com o botão direito, embora haja um caso em que um caractere TAB se expande para algo que não teria sem o PSReadline - mas isso tem mais a ver com como a entrada de várias linhas não está funcionando como esperado se você não usar PSReadline.

Mas meu ponto foi realmente mais simples - a experiência interativa foi planejada para ser o mais próximo possível, idealmente idêntico, de colocar o mesmo texto em um script. Esse recurso seria uma saída dessa intenção em um cenário comumente usado - clique com o botão direito.

Neste ponto, estou dizendo para fazer um julgamento de uma forma ou de outra sobre essa sugestão, estou apenas apontando algo que pode não ser óbvio para todos.

Clicar com o botão direito e colar poderia usar alguma modernização, colando todo o buffer da área de transferência no console como se você tivesse shift + inserido cada linha e depois executado dessa forma. Mesmo sem considerar esse problema, acho que seria útil por si só - quantas vezes você clicou com o botão direito do mouse e colou em algo que não estava certo (erros de análise) e viu um monte de mensagens de erro, talvez intercaladas com alguns comandos que foi executado? Isso pode ser bastante prejudicial, dependendo do que você está colando (opa, aquele comando cd não foi analisado corretamente, então eu permaneci no meu diretório C: \ atual quando o comando del *.* -r -fo executado. ..). Seria melhor se clicar com o botão direito e colar realmente colasse o bloco inteiro, e o PowerShell já lida bem com isso no lado da execução.

Tecnicamente, a experiência interativa hoje já é diferente de colocar o mesmo texto em um script porque clicar com o botão direito e colar executa os comandos à medida que são colados, em vez de como uma coleção de comandos. O resultado é que os erros de análise não impedem a execução parcial ao clicar com o botão direito e colar, enquanto o fazem nos scripts.

Além disso, para PowerShell ad-hoc interativo, acho que é bastante incomum que os usuários insiram comandos multilinhas digitando-os no console, e para os usuários que fazem isso hoje, eles podem continuar a fazê-lo como sempre fizeram feito. Para o resto de nós, pessoas normais, nossos pipelines estarão em uma única linha, a menos que cliquemos com o botão direito e colemos, o que, como foi apontado acima, pode, e provavelmente deve, ser melhorado para que a experiência interativa seja realmente o mais próximo possível , idealmente idêntico a colocar o mesmo texto em um script.

Tudo para dizer: +1 por ter o PowerShell suportando pipelines no início de uma linha sem caracteres de continuação de linha e uma solicitação para corrigir clique com o botão direito e colar para que haja melhor consistência entre o uso interativo e a experiência de script.

Clicar com o botão direito não é um recurso do PowerShell, é um recurso conhost. O Conhost nem sempre pode assumir que simular digitação é equivalente a colar sem alguma coordenação com o processo atual do console.

sim. Isso pode tornar o clicar com o botão direito e colar estranho. Exatamente da mesma maneira que else .

Isso tornaria os comandos (no console e nos arquivos) com vários pipes muito mais legíveis e, como apontado antes, teria exatamente o mesmo problema que if / else quando executado no prompt.

Até agora um | como o último caractere em uma linha funcionou como um caractere de continuação. O que essa mudança traz, especialmente se ela interromper o funcionamento do comportamento anterior

Enviado do meu iPad

Em 8 de março de 2017, às 17h04, Michael T Lombardi < [email protected] [email protected] > escreveu:

Isso tornaria os comandos (no console e nos arquivos) com vários pipes muito mais legíveis e, como apontado antes, teria exatamente o mesmo problema que if / else quando executado no prompt.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD .

Essa alteração exigiria necessariamente que | não pudesse ainda ser um caractere de continuação no EOL _ assim como_ no início de uma nova linha? Eu não esperava que isso acontecesse.

@RichardSiddaway é sobre legibilidade - isso surgiu várias vezes em discussões sobre quebra de linha no

Ter uma barra vertical como a primeira coisa na linha torna _realmente_ óbvio que é uma continuação - muito mais do que apenas recuá-la - particularmente se as linhas são longas e você não consegue ver facilmente a barra no final.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

@jaykul em seu exemplo acima do recuo é igualmente útil do ponto de vista da acuidade visual. O símbolo do tubo parece ser apenas um indicador adicional (e IMO desnecessário).
dado o seu exemplo, isso atrai tanto você?

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

A meu ver, isso parece bastante compreensível:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

é o recuo que ajuda (e é como eu costumo escrever isso)

FWIW, eu nunca entendi o uso do backtick em pipelines longos e tentei esmagá-lo sempre que o via em revisões de código, pois era desnecessário.

Eu prefiro explicitamente o pipe como o primeiro caractere, como em seu primeiro exemplo, @JamesWTruher (embora com um único espaço entre o pipe e o primeiro caractere do comando) - ele fornece um indicador visual muito claro e explícito de um pipeline contínuo . O recuo fornece uma inferência semelhante, mas menos explícita, ao rolar o código.

@Jaykul Isso interromperá completamente a experiência interativa de linha de comando. Por exemplo, digamos que você digite um comando e pressione Enter

PS> dir
>

Você consegue saída? Não, não precisa, porque o analisador está aguardando o próximo token que _pode_ ser uma continuação. Agora, bata na tecla de retorno. Nada acontece, exceto que você vê mais prompts porque o analisador ainda está esperando por um token para ver se é uma continuação.

PS> dir
>
>

OK - adicione | sort Length e pressione Enter.

PS> dir
>
>
> | sort Length
>

E ainda assim nada acontece porque _ainda_ pode haver um token de continuação, então ele ainda precisa ouvir uma nova linha. Agora você diz 'eu terminei com isso - não funciona, vamos apenas pegar a data'. Você digita Get-Date e pressiona return. Yay - você obtém saída. Mas não é de Get-Date . Não - você finalmente completou o comando dir | sort Length então esta é a saída que você vê. Nesse ínterim, o leitor de comandos está agora esperando que você complete o comando que você iniciou com Get-Date . Ou a coisa toda pode ser apenas um erro.

Esta seria uma experiência interativa horrível para qualquer usuário.

Podemos fazer isso funcionar apenas em arquivos? Sim - provavelmente, mas como @lzybkr mencionou, um dos nossos princípios básicos de design era que o que funcionava na linha de comando poderia simplesmente ser colado em um arquivo e vice-versa. Oferecemos até suporte para colagem de documentos do Word com caracteres emdash e endash.

Então, embora eu realmente goste de como '|' olha para o início da linha em coisas como correspondência de padrão Haskell:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
não funcionará para PowerShell.

Com a ressalva de que sou um bebê recém-nascido quando se trata de partes internas, aqui estão algumas observações:

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

Como um aparte, eu esperaria / estaria bem com a seguinte falha no prompt sem devoluções suaves, como um não acariciado if / else faz:

Get-Process
| Select-Object -First 1

Eu não me importo particularmente com a legibilidade, especialmente a legibilidade de relance, quando interativo no prompt (porque, geralmente, eu escrevi momentos atrás), mas é uma das minhas principais preocupações quando estou escrevendo / mantendo scripts e módulos ou depurar o trabalho de outras pessoas, etc.

Para abordar @JamesWTruher - eu esperaria que as pessoas não

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

@BrucePay Então, certo. A experiência interativa não iria _explicitamente_ suportá-lo.

Se vocês realmente acham que não há diferenças entre interativo e scripts, _você precisa tentar usar o PowerShell sem PSReadLine de vez em quando_.

Tente usar o console no código ISE ou VS

A menos que você tenha PSReadline para lidar com as exceções do tipo "bloco de instrução ausente" ou "elemento de tubo vazio", você não pode colocar uma nova linha após um tubo, nem escrever chaves no estilo Allman. Você certamente não pode escrever nenhum destes:

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

Portanto, sim, este seria _ainda_ outro lugar_ onde você pode ter uma quebra de linha no script, mas não no console. Mas já temos muitos deles (_especialmente_ se você não estiver usando PSReadLine).

Para fazer referência ao código que @Jaykul 1 e @JamesWTruher 2 tinham, eu uso este:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

Como foi apontado, o recuo torna isso muito mais fácil de ler ao fazer a varredura rápida do código - eu sei que essas três linhas de código estão 'amarradas' sem ter que olhar para o final para ver o tubo. A legibilidade para mim é uma das coisas mais importantes quando estou escrevendo um código.

Às vezes, adiciono o caractere de crase no final após o tubo, mas quando me lembro de _não é necessário_, eu me flagelo por isso. É um hábito que estou tentando quebrar (o backtick, não o briching).

Copiar e colar no console com PSReadline não me deu nenhum problema (eu me lembro), então não é algo que eu vou entrar no meio e adicionar à discussão.

Ter o tubo na próxima linha em vez de no final da linha é uma ideia muito parecida com o F #, em que você pode fazer coisas como esta:

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

E eu sou a favor de qualquer coisa que torne o PS um pouco mais funcional (trocadilho intencional);)

Não apenas F #, mas também Elm , Haskell , Elixir e até mesmo o guia de estilo de shell do Google (e observe aqui que eles precisam escapar das novas linhas para fazer isso ...).

@michaeltlombardi Tal como acontece com os shells Unix, você pode escapar de novas linhas no PowerShell se quiser

Get-Process | Where CPU | Where Path `
| Get-Item | Where FullName -match "AppData" `
| Sort-Object FullName -Unique

F # é sensível a espaços em branco (regra de impedimento) de maneiras que o PowerShell não é. Elm, Haskell e Elixir não são, é claro, conchas.

_ queixas sobre hosts ruins _...

O interpretador fornece informações ao aplicativo host lançando uma exceção IncompleteParse . Cabe à implementação do host capturar isso e solicitar mais informações. Se o host estiver fazendo isso errado, reclame com o proprietário do host.

Se vocês realmente acham que não há diferenças entre interativo e scripts, você precisa tentar usar o PowerShell sem PSReadLine de vez em quando.

Usei o PowerShell por mais de uma década sem o PSReadLine. Isso é suficiente?

Este erro ocorre no prompt, a menos que esteja usando retornos suaves, observe as duas linhas em branco;

Como isso é tratado depende da implementação do host. Abra um problema nos hosts ofensivos se quiser que isso seja alterado.

exatamente o mesmo problema que if / else quando executado no prompt.

Sim. É ambíguo. Desculpa. Eu não conseguia pensar em uma maneira de fazer isso funcionar de maneira confiável. Se tivéssemos optado por OTBS em vez de combinar o estilo de chave do C #, isso não teria sido significativo. Na verdade, teria havido muitas vantagens em usar OTBS (por exemplo, DSLs). Observe também: no host do console original, isso "funcionou" porque depois de receber a primeira IncompleteParse exceção, o host apenas continuou lendo as linhas até atingir uma linha em branco e, em seguida, executou o resultado. Mas isso significa que você sempre teve que atingir uma nova linha extra.

@Jaykul Então você quer o oposto da diretiva #light do F #? Algo como #pesado, onde os espaços são irrelevantes e os pontos-e-vírgulas são obrigatórios?

O escape de novas linhas no PS é, na minha opinião, mais problemático do que na maioria dos idiomas. O personagem de escape de PS é o maldito cretino . O realce de sintaxe realmente não o destaca na maior parte - a maioria dos esquemas de realce o torna uma cor bastante opaca.

Acrescente a isso o fato de que quando você volta e edita algo cheio de crases, a probabilidade de você perder acidentalmente uma crase ou duas que foram perdidas no meio das edições é muito alta.

Eu usaria essa forma se rastrear erros de crista não fosse como encontrar uma agulha em um palheiro. Não, acho que seria melhor permitir o formato de tubo no início como um estilo próprio, sem obrigar o escape da linha. : /

@ vexx32 Embora eu concorde que '`' é difícil de ver, '|' não é.

@Jaykul Então você quer o oposto da diretiva #light do F #? Algo como #pesado, onde os espaços são irrelevantes e os pontos-e-vírgulas são obrigatórios?

Não, @BrucePay , só quero outro truque de sintaxe como este:

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

o que me permite escrever coisas _ nitidamente_ em scripts, sem me preocupar se funciona quando você está digitando no console ou não.

@BrucePay correto, e eu tenho algum código usando esses crases, mas o que estamos buscando aqui é a capacidade de escrever o código sem eles por todos os motivos @ vexx32 listados.

É totalmente justo apontar que vários comportamentos existentes no PowerShell dos quais as pessoas dependem são, na verdade, o resultado da implementação do host, então, obrigado por esclarecer essas coisas! Por outro lado, isso também implica que há coisas na linguagem que já quebram essas expectativas, a menos que a implementação do host faça um trabalho extra para lidar com elas, certo?

@michaeltlombardi Implementações de host ruins resultarão em uma experiência interativa pobre, mas não afetarão a linguagem em si. Dito isso, a experiência interativa é muito importante, pois a maioria dos 'scripts' do PowerShell são digitados interativamente.

que estamos buscando aqui é a capacidade de escrever o código sem eles

Meu ponto é que se você colocar | no final da linha, a continuação é implícita e nenhum caractere de continuação é necessário conforme você solicita. E o símbolo | é fácil de ver. E use recuo para tornar a estrutura do código claramente visível. Ao contrário do F # ou Python, não impomos o recuo porque o PowerShell é um shell e às vezes você precisa escrever um código muito denso.

@Jaykul

sem se preocupar se funciona ou não ao digitar no console.

A experiência do console continua sendo um cenário primário para nós e para a maioria de nossos clientes. No entanto, temos um meta-recurso chegando para oferecer suporte a recursos experimentais. Poderíamos tentar fazer o que você quiser, expor como um recurso experimental, e então ver que tipo de feedback recebemos sobre a experiência geral.

Eu entendo perfeitamente que a experiência do console é fundamental. Meu ponto é simplesmente que isso não deve quebrar o console, como você sugeriu em seu _primeiro_ comentário.

Deve se comportar no console _ da mesma maneira_ que o segundo catch acima: você só pode digitá-lo em um console onde tenha um ReadLine multilinha como PSReadLine e pode Shift+Enter para injetar um linha extra (ou você pode colá-la) - não precisa mudar o comportamento existente.

Afinal, esse é um recurso que visa melhorar a formatação do código, não reduzir a digitação. Ele precisa funcionar na experiência de script, não no console interativo.

Mas uma das promessas que fizemos ao usuário desde o início foi que você poderia colar de um script (exemplo, etc.) no console e fazê-lo funcionar. Isso incluía até mesmo a colagem de documentos do Word com emdashes etc. Copiar e colar é de longe a forma mais comum de reutilização (fizemos um estudo para validar isso)

Direito. Mas a coisa de copiar e colar atualmente só é _fulamente_ verdadeira enquanto você estiver colando no Ctrl + V do PSReadLine e não clicando com o botão direito do mouse - e essa mudança funcionaria lá também. Ou seja, seria necessário um ReadLine capaz de colar multilinhas, mas funcionaria por padrão no PowerShell 5+

Como mencionei acima , há alguns casos (if / else, try / catch, comments, chaves Allman, etc) em que _já_ não é o caso se você _não_ tiver PSReadLine.

Minha opinião é que mais um caso extremo na lista de problemas com hosts não PSReadLine não é uma razão grande o suficiente para excluir um recurso - afinal, essa sintaxe não funcionaria no PowerShell 4 ou 5 de qualquer maneira, então ' Nunca funcionarei no ISE ou em hosts que não sejam PSReadline. _Está me deixando um pouco louco_ que estejamos gastando tanto esforço debatendo um _mais_ problema com colar em {{não-nosso-problema}}, mas estamos bem com o fato de que seria uma sintaxe que não funciona em versões mais antigas versões do PowerShell ...

PS Eu usei o argumento de colagem como uma das justificativas para as BestPractices escolherem OTBS em

Eu _realmente_ gostaria que tivéssemos escolhido OTBS. DSLs teriam sido muito mais simples.

OTBS é, obviamente, o caminho único e verdadeiro ....

@BrucePay - Tenho certeza de que ainda existem algumas pessoas que colam linhas de comando multi-linha e não usam Ctrl + v , mas acho que não são tantas pessoas, e eles deveriam se adaptar, colando sem clicar com o botão direito ou Alt + barra de espaço , e, p é superior de várias maneiras.

Acho que é muito razoável considerar essa mudança.

Alguém pode me apontar a direção certa para o que precisaria acontecer para fazer este trabalho? Eu gostaria de pelo menos fazê-lo funcionar e ver como é ... e então talvez colocá-lo atrás de um sinalizador experimental para que possamos testá-lo um pouco se necessário - mas, para ser honesto, nem tenho certeza se isso é realmente necessário; afinal, isso não mudará abertamente nada sobre a experiência atual, apenas adicione uma nova.

Dado que como é um elemento de tubo no início de uma linha é um erro instantâneo no presente, não é um padrão de codificação que está sendo atualmente seguida sem também o uso de novas linhas escaparam, e que também será afetado por fazer essa alteração. Então realmente ... nada a perder aqui, tudo a ganhar?

Isso provavelmente não funcionará, mas deve ajudar você a começar:

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

Você está certo, isso não chega lá. Pelo menos em parte porque atualmente o analisador não se preocupa com o número de novas linhas; tantas instruções nunca são executadas . Tenho algumas ideias potenciais sobre como proceder, então você me deu um quebra-cabeça intrigante, obrigado! 💖

Tópicos como este realmente mostram os imensos benefícios que o open source PowerShell trouxe para nós e para todos nós podermos ter uma boa e aberta discussão com a equipe de produto, MVP's, membros da comunidade de confiança e aqueles que são novos na linguagem como esta é fantástico. Apenas para citar a resposta de @Jaykul anteriormente neste tópico, este seria o objetivo final ideal.

A parte principal do que @Jaykul disse acima é que tendemos a achar mais fácil compreender e ler que a continuação de um comando está no início de uma linha em vez de no final de uma linha

@RichardSiddaway é sobre legibilidade - isso surgiu várias vezes em discussões sobre quebra de linha no

Ter uma barra vertical como a primeira coisa na linha torna _realmente_ óbvio que é uma continuação - muito mais do que apenas recuá-la - particularmente se as linhas são longas e você não consegue ver facilmente a barra no final.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Então, sim, eu gostaria de poder fazer isso no futuro

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Preciso fazer outra tentativa em algum momento em breve. É um quebra-cabeça intrigante, mas ainda não sei como resolvê-lo. 😕

Eu concordo com os dois @kilasuit no sentido de que isso é incrível, agora temos uma versão de código aberto do PowerShell. Como um aparte eu instalei no Manjaro Linux ontem e fiquei um pouco surpreso que ele construiu tudo do zero. E tão rápido.

Também concordo com @RichardSiddaway que seria bom ter a _opção_ de usar o caractere de continuação de linha no início da linha. Sou um grande defensor da codificação para facilitar a leitura, então o recuo (ou seja, a primeira opção) é o que eu uso e estou feliz com isso. Na verdade, não gosto da aparência da segunda opção (acho que parece feia :)), mas elimina qualquer ambigüidade. E eu defendo que as pessoas têm opções, se isso melhorar a legibilidade!

Ontem à noite tive vontade de mexer no analisador, e isso sempre me incomodou ( sempre preferi tubos no início da linha ). Aqui está o resultado:

A única dúvida que tenho é se isso precisa ou não ser escondido atrás de uma bandeira experimental. Se os testes são suficientes, por que torná-lo experimental, já que não afeta nenhuma funcionalidade existente? Pensamentos?

Agora, para encerrar em alguns testes Pester ...

Não acho que seja realmente necessário um sinalizador experimental, desde que o comportamento seja previsível, consistente e testável. Não está quebrando nenhum comportamento pré-existente, pelo que posso dizer.

Realmente não parece que haja qualquer controvérsia sobre o design, também.

Além disso, é uma pena que o PowerShell permite que nomes de comando comecem com "-". Caso contrário, provavelmente poderíamos encapsular parâmetros em novas linhas sem crases também. Claro que temos splatting, mas isso pode funcionar _com IntelliSense e realce de sintaxe_ se os nomes dos comandos não corresponderem aos nomes dos parâmetros:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

Estou aguardando a sequência semelhante a um splat, mas definitivamente acho que a opção de tê-lo como primeiro personagem é ótima. Claro que é diferente entre interativo e script, mas isso é consistente com a forma como o PowerShell já é.

A única dúvida que tenho é se isso precisa ou não ser escondido atrás de uma bandeira experimental. Se os testes são suficientes, por que torná-lo experimental, já que não afeta nenhuma funcionalidade existente? Pensamentos?

Não sei por que a equipe MSFT está tão passiva da última vez, mas se seu código estiver sob a tag experimental, eu poderia revisar rapidamente. Também podemos habilitar o recurso por padrão em powershell.config.json.

é uma pena que o PowerShell permite que nomes de comando comecem com "-".

Estou totalmente de acordo. Acho que vale a pena discutir a fundo na nova edição. (Existem outros personagens que poderíamos colocar de lado.)

"Um elemento de tubo vazio não é permitido", portanto, não deve haver problema de compatibilidade de quebra se um tubo foi usado para a continuação da linha e o início da próxima linha, ao mesmo tempo:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

Que responde a muitas das reclamações - sem backticks, cano no início de uma linha para indicação visual de continuidade; nenhuma mudança no comportamento do prompt interativo após digitar a primeira linha, porque ele pode dizer se é necessário esperar uma linha contínua; não tem muita confusão com o operador || reservado porque ele é dividido em várias linhas; não é mais digitar do que usar um backtick e um pipe; não precisa ter problemas com uma linha de comentário entre os exemplos de if/else , try/catch Jaykul.

@HumanEquivalentUnit - Não posso dizer que sou um fã dessa sugestão porque eu, como escritor de roteiro, posso decidir que quero remover as novas linhas de um script para uso em cmdline e ficaria com uma única linha impraticável e não intuitiva aquele IMO
parece atroz

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

Que

@kilasuit essa linha editada parece estranha (não parece atroz para mim, apenas estranha), mas isso é realmente diferente do código com crases que é válido agora, se você removeu as linhas sem remover a continuação da linha? Você atualmente sofre desse problema com o código de crase?

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

Se você me perguntar, esse é apenas um motivo claro pelo qual o RP de Kirk é bem-vindo, para ser honesto. Não exigir backticks ou um tubo adicional é muito bom ao condensar linhas.

A solicitação inicial foi implementada.
Agora discutiremos https://github.com/PowerShell/PowerShell-RFC/pull/179