Powershell: ¿Podemos utilizar | en la siguiente línea como carácter de continuación?

En un script, sí, pero eso rompería la capacidad de usar el clic derecho de la vieja escuela o Alt + e, p pegar en la consola porque después de ingresar, tendrías una línea de comando completa.

Discusión relacionada # 2819

Veo una mala experiencia de usuario para la sesión interactiva: después del primer NewLine analizador esperará el siguiente NewLine o saltará espacios hasta | o NewLine - esto confundirá al usuario .

Para el script, esta es una solicitud para eliminar un carácter de continuación `(comillas invertidas) a tiempo, ya que siempre podemos escribir:

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

El analizador ya hace esto en otros lugares.

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

@lzybkr, obviamente, hacer que el analizador sea capaz de entenderlo no significa que la gente _debe_ escribir varias líneas de esa manera; muchas personas han adoptado el estilo stroustrup como el anterior, o incluso "apoyarse en su propia línea" y otras cosas de estilo que rompen el pegado (especialmente desde que PSReadLine se equivocó con el clic derecho e hizo que Ctrl + V funcionara). Eso no debería hacer ninguna diferencia.

@iSazonov de forma interactiva, si presionas enter, no va a esperar, solo lo ejecutará. Al igual que ahora con el else arriba. Puede presionar shift + enter para escribirlo en la consola (cuando tiene PSReadLine).

PSReadline no se mete con el clic derecho, aunque hay un caso de esquina en el que un carácter TAB se expande a algo que no tendría sin PSReadline, pero eso tiene más que ver con cómo la entrada de varias líneas no funciona como esperado si no usa PSReadline.

Pero mi punto era realmente más simple: la experiencia interactiva estaba destinada a ser lo más cercana posible, idealmente idéntica, a poner el mismo texto en un guión. Esta característica sería una desviación de esa intención en un escenario de uso común: clic derecho.

En este punto, estoy diciendo que hacer un juicio de una forma u otra sobre esta sugerencia, solo estoy señalando algo que podría no ser obvio para todos.

Hacer clic con el botón derecho y pegar podría usar algo de modernización, pegar todo el búfer del portapapeles en la consola como si hubiera ingresado shift + cada línea y luego ejecutarlo de esa manera. Incluso sin considerar este problema, creo que sería útil por sí mismo: ¿cuántas veces hizo clic con el botón derecho y pegó algo que no estaba del todo correcto (errores de análisis) y vio un montón de mensajes de error, tal vez intercalados con algunos comandos que ejecutó? Eso podría ser bastante dañino, dependiendo de lo que estuvieras pegando (vaya, ese comando cd no se analizó correctamente, así que me quedé en mi directorio C: \ actual cuando se ejecutó el comando del *.* -r -fo . ..). Sería mejor si hacer clic con el botón derecho y pegar realmente pegara todo el bloque, y PowerShell ya lo maneja bien en el lado de la ejecución.

Técnicamente, la experiencia interactiva actual ya es diferente de poner el mismo texto en un script porque hacer clic con el botón derecho y pegar ejecuta los comandos a medida que se pegan, en lugar de como una colección de comandos. El resultado es que los errores de análisis no impiden la ejecución parcial al hacer clic con el botón derecho y pegar, mientras que lo hacen en los scripts.

Además, para PowerShell interactivo y ad-hoc, creo que es bastante poco común que los usuarios ingresen comandos de varias líneas escribiéndolos en la consola, y para los usuarios que hacen esto hoy, pueden continuar haciéndolo como siempre lo han hecho. hecho. Para el resto de nosotros, gente normal, nuestras canalizaciones estarán en una sola línea a menos que hagamos clic con el botón derecho y peguemos, lo que, como se señaló anteriormente, podría, y probablemente debería, mejorarse para que la experiencia interactiva sea realmente lo más cercana posible. , idealmente idéntico a poner el mismo texto en un guión.

Todo para decir: +1 por tener canalizaciones de soporte de PowerShell al comienzo de una línea sin caracteres de continuación de línea, y una solicitud para corregir el clic derecho y pegar para que haya una mejor coherencia entre el uso interactivo y la experiencia de secuencias de comandos.

El clic derecho no es una función de PowerShell, es una función de reserva. Conhost no siempre puede asumir que la simulación de mecanografía es equivalente a pegar sin alguna coordinación con el proceso actual de la consola.

Si. Puede hacer que pegar con el botón derecho sea incómodo. Exactamente de la misma manera que lo hace else .

Esto haría que los comandos (tanto en la consola como en los archivos) con múltiples conductos sean mucho más legibles y, como se señaló anteriormente, tiene exactamente el mismo problema que if / else cuando se ejecuta en el indicador.

Hasta ahora un | ya que el último carácter de una línea ha funcionado como carácter de continuación. ¿Qué aporta este cambio, especialmente si detiene el funcionamiento del comportamiento anterior?

Enviado desde mi iPad

El 8 de marzo de 2017, a las 17:04, Michael T Lombardi < [email protected] [email protected] > escribió:

Esto haría que los comandos (tanto en la consola como en los archivos) con múltiples conductos sean mucho más legibles y, como se señaló anteriormente, tiene exactamente el mismo problema que if / else cuando se ejecuta en el indicador.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD .

¿Este cambio requeriría necesariamente que un | no pudiera seguir siendo un carácter de continuación en EOL _ así como_ al comienzo de una nueva línea? No lo esperaría.

@RichardSiddaway se trata de legibilidad: esto ha surgido varias veces en las discusiones sobre el

Tener un carácter de tubería como lo primero en la línea hace que sea _realmente_ obvio que es una continuación, mucho más que solo sangrarlo, particularmente si las líneas son largas y no se puede ver fácilmente la tubería al 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 en su ejemplo anterior, la sangría es igualmente útil desde la perspectiva de la agudeza visual. El símbolo de la tubería parece ser solo un indicador adicional (e IMO innecesario).
dado su ejemplo, ¿esto le atrae tanto?

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

A mi modo de ver, esto parece bastante comprensible:

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

es la sangría lo que ayuda (y así es como suelo escribir esto)

FWIW, nunca entendí el uso de la comilla invertida en tuberías largas y traté de aplastarlo cada vez que lo vi en revisiones de código, ya que no era necesario.

Prefiero explícitamente la tubería como primer carácter, como en su primer ejemplo, @JamesWTruher (aunque con un solo espacio entre la tubería y el primer carácter del comando): da un indicador visual muy claro y explícito de una tubería continua . La sangría da una inferencia similar, pero menos explícita, al desplazarse por el código.

@Jaykul Esto romperá por completo la experiencia de la línea de comandos interactiva. Por ejemplo, digamos que escribe un comando y presiona regresar

PS> dir
>

¿Obtienes salida? No, no lo hace porque el analizador está esperando el siguiente token que _podría_ ser una continuación. Ahora pulsa la tecla de retorno. No sucede nada excepto que vea más mensajes porque el analizador todavía está esperando un token para ver si es una continuación.

PS> dir
>
>

OK - agregue | sort Length y presione regresar.

PS> dir
>
>
> | sort Length
>

Y aún así no sucede nada porque _todavía_ podría haber un token de continuación, por lo que aún debe escuchar una nueva línea. Ahora dices 'he terminado con esto, no funciona, solo obtengamos la fecha'. Escribe Get-Date y presiona regresar. Sí, obtienes salida. Pero no es de Get-Date . No, finalmente ha completado el comando dir | sort Length así que esta es la salida que ve. Mientras tanto, el lector de comandos ahora está esperando que complete el comando que comenzó con Get-Date . O puede que todo sea un error.

Esta sería una experiencia interactiva horrible para cualquier usuario.

¿Podríamos hacer que funcione solo en archivos? Sí, probablemente, pero como mencionó @lzybkr , uno de nuestros principios de diseño base era que lo que funcionaba en la línea de comandos simplemente se podía pegar en un archivo y viceversa. Incluso admitimos pegar desde documentos de Word con caracteres emdash y endash.

Entonces, aunque realmente me gusta cómo '|' mira el comienzo de la línea en cosas como la coincidencia de patrones de Haskell:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
no funcionará para PowerShell.

Con la advertencia de que soy un bebé recién nacido en lo que respecta a las partes internas, aquí hay algunas observaciones:

# 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 acotación al margen, esperaría / estaría de acuerdo con el siguiente error en el indicador sin devoluciones suaves, como un no abrazado if / else lo hace:

Get-Process
| Select-Object -First 1

No me importa particularmente la legibilidad, especialmente la legibilidad de un vistazo, cuando interactúo en el indicador (porque, generalmente, lo escribí hace unos momentos) pero es una de mis principales preocupaciones cuando estoy escribiendo / manteniendo scripts y módulos o depurar el trabajo de otras personas, etc.

Para abordar @JamesWTruher , esperaría que la gente no sangrara las líneas de continuación si la tubería estuviera allí en la parte delantera como una indicación de lo que estaba sucediendo:

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 Entonces, claro. La experiencia interactiva no lo respaldaría _explícitamente_.

Si realmente creen que no hay diferencias entre los scripts interactivos y los scripts, _deben intentar usar PowerShell sin PSReadLine de vez en cuando_.

Intente usar la consola en ISE o VS Code

A menos que tenga PSReadline para manejar las excepciones de tipo "bloque de declaración faltante" o "elemento de tubería vacía", no puede poner una nueva línea después de una tubería, ni escribir llaves al estilo Allman. Ciertamente no puedes escribir ninguno de estos:

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

Así que sí, este sería _sin embargo, otro lugar_ donde puede tener un salto de línea en el script pero no en la consola. Pero ya tenemos muchos de esos (_especialmente_ si no está usando PSReadLine).

Para hacer referencia al código que tenían @Jaykul 1 y @JamesWTruher 2 , uso esto:

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

Como se señaló, la sangría hace que esto sea mucho más fácil de leer cuando se escanea rápidamente el código; sé que esas tres líneas de código están 'unidas' sin tener que mirar el final para ver la tubería. La legibilidad para mí es una de las cosas más importantes cuando escribo código.

A veces agrego el carácter de tilde al final después de la tubería, pero cuando recuerdo que no es necesario, me flagelé por ello. Es un hábito que estoy tratando de romper (la tilde al revés, no el briching).

Copiar y pegar en la consola con PSReadline no me ha dado ningún problema (puedo recordarlo) por lo que no es algo en lo que voy a meterme en el medio y agregar a la discusión.

Tener la tubería en la siguiente línea en lugar de al final de la línea es una idea muy similar a F #, donde puedes hacer cosas como esta:

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

Y estoy a favor de cualquier cosa que haga que PS sea un poco más funcional (juego de palabras);)

No solo F #, sino también Elm , Haskell , Elixir e incluso la guía de estilo de shell de Google (y tenga en cuenta que aquí tienen que escapar de las nuevas líneas para hacerlo ...).

@michaeltlombardi Al igual que con los shells de Unix, puede escapar de las nuevas líneas en PowerShell si lo desea

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

F # es sensible a los espacios en blanco (regla de fuera de juego) en formas que PowerShell no lo es. Elm, Haskell y Elixir son, por supuesto, no conchas.

_quejas sobre hosts defectuosos _...

El intérprete proporciona información a la aplicación principal lanzando una excepción IncompleteParse . Depende de la implementación del host detectar esto y solicitar más información. Si el anfitrión está haciendo esto mal, presente una queja al propietario del anfitrión.

Si ustedes realmente piensan que no hay diferencias entre los scripts interactivos y los scripts, deben intentar usar PowerShell sin PSReadLine de vez en cuando.

Usé PowerShell durante más de una década sin PSReadLine. ¿Es suficiente?

Estos errores en el indicador, a menos que se utilicen devoluciones suaves, tenga en cuenta las dos líneas en blanco;

La forma en que se maneja depende de la implementación del host. Abra un problema en los hosts infractores si desea que esto cambie.

exactamente el mismo problema que if / else lo hace cuando se ejecuta en el indicador.

Sí. Es ambiguo. Perdón. No pude pensar en una forma de hacerlo funcionar de manera confiable. Si hubiéramos optado por OTBS en lugar de igualar el estilo de corsé de C #, esto no habría sido significativo. De hecho, habría habido muchas ventajas al utilizar OTBS (por ejemplo, DSL). También tenga en cuenta: en el host de la consola original, esto "funcionó" porque después de recibir la primera excepción IncompleteParse , el host siguió leyendo líneas hasta que tocó una línea en blanco, luego ejecutó el resultado. Pero esto significa que siempre tuvo que alcanzar una nueva línea adicional.

@Jaykul Entonces, ¿quieres lo contrario de la directiva #light de F #? ¿Algo como #pesado donde los espacios son irrelevantes y el punto y coma son obligatorios?

Escapar de las nuevas líneas en PS es, en mi opinión, más problemático que con la mayoría de los idiomas. El personaje de escape de PS es el jodido backtick . El resaltado de sintaxis realmente no lo hace destacar en su mayor parte; la mayoría de los esquemas de resaltado lo hacen con un color bastante opaco.

Agregue a eso el hecho de que cuando regresa y edita algo lleno de comillas inversas, la probabilidad de que accidentalmente se pierda una o dos comillas inversas que se extraviaron en medio de las ediciones es bastante alta.

Usaría ese formulario si rastrear los errores de las comillas inversas no fuera como encontrar una aguja en un pajar. No, creo que sería mejor permitir el formato de tubería al principio como un estilo por derecho propio, sin obligar a escapar de la línea. : /

@ vexx32 Aunque estoy de acuerdo en que '`' es difícil de ver, '|' no es.

@Jaykul Entonces, ¿quieres lo contrario de la directiva #light de F #? ¿Algo como #pesado donde los espacios son irrelevantes y el punto y coma son obligatorios?

No @BrucePay , solo quiero otro truco de sintaxis como este:

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

lo que me permite escribir cosas _ prolijamente_ en scripts, sin preocuparme de si funciona cuando estás escribiendo en la consola o no.

@BrucePay es correcto, y tengo un código que usa esas comillas, pero lo que buscamos aquí es la capacidad de escribir el código sin ellos por todas las razones que @ vexx32 enumeró.

Es totalmente justo señalar que varios comportamientos existentes en PowerShell en los que la gente confía son en realidad el resultado de la implementación del host, ¡así que gracias por aclarar esas cosas! Por otro lado, esto también implica que hay cosas en el lenguaje que ya rompen esas expectativas a menos que la implementación del host haga un trabajo adicional para manejarlas, ¿verdad?

@michaeltlombardi Las implementaciones de host incorrectas darán como resultado una experiencia interactiva deficiente, pero no afectarán al lenguaje en sí. Dicho esto, la experiencia interactiva es muy importante ya que la mayoría de los 'scripts' de PowerShell se escriben de forma interactiva.

lo que buscamos aquí es la capacidad de escribir el código sin ellos

Mi punto es que si pones | al final de la línea, la continuación es implícita y no se necesita ningún carácter de continuación como lo solicitas. Y el símbolo | es fácil de ver. Y use sangría para hacer que la estructura del código sea claramente visible. A diferencia de F # o Python, no aplicamos la sangría porque PowerShell es un shell y, a veces, es necesario escribir un código muy denso.

@Jaykul

sin preocuparse de si funciona cuando está escribiendo en la consola o no.

La experiencia de la consola sigue siendo un escenario principal para nosotros y la mayoría de nuestros clientes. Sin embargo, tenemos una metacaracterística próxima para admitir funciones experimentales. Podríamos intentar hacer lo que quieras, expuesto como una función experimental, y luego ver qué tipo de comentarios recibimos sobre la experiencia general.

Entiendo totalmente que la experiencia de la consola es primordial. Mi punto es simplemente que esto no debería romper la consola, como sugirió en su _primer_ comentario.

Debería comportarse en la consola _ de la misma manera_ que el segundo catch anterior: solo puede escribirlo en una consola donde tenga una ReadLine multilínea como PSReadLine y pueda Shift+Enter inyectar un línea adicional (o puede pegarla): no es necesario cambiar el comportamiento existente en absoluto.

Después de todo, esta es una característica destinada a mejorar el formato del código, no a reducir la escritura. Debe funcionar en la experiencia de creación de scripts, no en la consola interactiva.

Pero una de las promesas que le hicimos al usuario desde el principio fue que podía pegar un script (ejemplo, etc.) en la consola y hacer que funcionara. Esto incluso incluía pegar documentos de Word con emdashes, etc. Copiar y pegar es, con mucho, la forma más común de reutilización (hicimos un estudio para validar esto)

Derecha. Pero la cosa de copiar y pegar actualmente solo es _ completamente_ verdadera solo mientras pegue en Ctrl + V de PSReadLine y no haciendo clic con el botón derecho, y este cambio también funcionaría allí. Es decir, requeriría una ReadLine capaz de pegar varias líneas, pero funcionaría de forma predeterminada en PowerShell 5+

Como mencioné anteriormente , hay bastantes casos (if / else, try / catch, comments, llaves de Allman, etc.) en los que _ya_ no es el caso si _no_ tiene PSReadLine.

Mi opinión es que un caso extremo más en la lista de problemas con hosts que no son de PSReadLine no es una razón lo suficientemente importante para excluir una función; después de todo, esta sintaxis no funcionaría en PowerShell 4 o 5 de todos modos, por lo que ' Nunca trabajaré en ISE o en hosts que no sean PSReadline. Me está _ volviendo un poco loco_ que estemos dedicando tanto esfuerzo a debatir un _más_ problema al pegar en {{no-nuestro-problema}}, pero estamos bien con el hecho de que sería una sintaxis que no funciona en versiones anteriores. versiones de PowerShell ...

PD: He usado el argumento de pegar como una de las justificaciones para BestPractices eligiendo OTBS en lugar de Stroustrup o Allman , pero definitivamente voy a hacer referencia a este hilo en el libro ahora 😁

Realmente deseo que hubiéramos ido con OTBS. Los DSL habrían sido mucho más sencillos.

OTBS es, por supuesto, la única forma verdadera ...

@BrucePay : estoy seguro de que todavía hay algunas personas que pegan líneas de comando de varias líneas y no usan Ctrl + v , pero supongo que no muchas personas, y deberían adaptarse, pegando sin hacer clic derecho o Alt + barra espaciadora , e, p es superior en múltiples formas.

Creo que es muy razonable considerar este cambio.

¿Alguien puede indicarme la dirección correcta de lo que debería suceder para que esto funcione? Me gustaría al menos hacerlo funcionar y ver cómo es ... y luego tal vez ponerlo detrás de una bandera experimental para que podamos probarlo un poco si es necesario, pero honestamente ni siquiera estoy seguro de si eso es realmente necesario; después de todo, esto no cambiará abiertamente nada sobre la experiencia actual, solo agregue una nueva.

Dado que como-es un elemento de tubo al comienzo de una línea es un error instantáneo en la presente, no es un patrón de codificación que se está siguiendo actualmente sin también el uso de las nuevas líneas escapado, que también será afectado por hacer este cambio. Así que realmente ... ¿nada que perder aquí, todo que ganar?

Esto probablemente no funcionará, pero debería ayudarlo a comenzar:

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)
                 {

Tienes razón, eso no llega del todo. Al menos en parte porque actualmente al analizador no le importa el número de nuevas líneas; tantas declaraciones nunca se ejecutan . Tengo algunas ideas potenciales sobre cómo proceder, así que me has dado un acertijo intrigante, ¡gracias! 💖

Thread's like this realmente muestra los inmensos beneficios que nos ha brindado PowerShell de código abierto y que todos podamos tener una discusión buena y abierta con el equipo de producto, los MVP, los miembros de la comunidad de confianza y aquellos que son nuevos en el lenguaje como este. fantástico. Solo para citar la respuesta de @Jaykul anteriormente en este hilo, este sería el objetivo final ideal.

La parte clave de lo que dijo @Jaykul anteriormente es que tendemos a encontrar más fácil comprender y leer que la continuación de un comando está al principio de una línea en lugar de al final de una línea.

@RichardSiddaway se trata de legibilidad: esto ha surgido varias veces en las discusiones sobre el

Tener un carácter de tubería como lo primero en la línea hace que sea _realmente_ obvio que es una continuación, mucho más que solo sangrarlo, particularmente si las líneas son largas y no se puede ver fácilmente la tubería al 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

Así que sí, me gustaría poder hacer esto en el futuro.

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

Necesito intentarlo de nuevo en algún momento pronto. Es un acertijo intrigante, pero todavía no sé cómo resolverlo. 😕

Estoy de acuerdo con @kilasuit en que esto es increíble, ahora tenemos una versión de código abierto de PowerShell. Además, ayer lo instalé en Manjaro Linux y me asombró un poco que lo construyera todo desde cero. Y tan rápido.

También estoy de acuerdo con @RichardSiddaway en que sería bueno poder tener la _opción_ de usar el carácter de continuación de línea al comienzo de la línea. Soy un gran defensor de la codificación para la legibilidad, por lo que la sangría (es decir, la primera opción) es lo que uso y estoy contento. De hecho, no me gusta el aspecto de la segunda opción (creo que se ve feo :)) pero elimina cualquier ambigüedad. ¡Y estoy totalmente a favor de que la gente tenga opciones si mejora la legibilidad!

Anoche tuve ganas de jugar con el analizador, y esto siempre me molestó ( siempre he preferido las tuberías al principio de la línea ). Aquí está el resultado:

La única pregunta que tengo es si esto debe ocultarse detrás de una bandera experimental. Si las pruebas son suficientes, ¿por qué hacerlo experimental en absoluto, ya que no afecta ninguna funcionalidad existente? ¿Pensamientos?

Ahora para resumirlo en algunas pruebas de Pester ...

No creo que realmente necesite una bandera experimental, siempre que el comportamiento sea predecible, consistente y comprobable. Por lo que yo sé, no está rompiendo ningún comportamiento preexistente.

Tampoco parece que haya ninguna disputa sobre el diseño.

También como nota al margen, es una lástima que PowerShell permita que los nombres de los comandos comiencen con "-". De lo contrario, probablemente también podríamos ajustar los parámetros en nuevas líneas sin comillas invertidas. Seguro que tenemos splatting, pero esto podría funcionar _con Intellisense y Syntax Highlighting_ si los nombres de los comandos no pueden coincidir con los nombres de los 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

Estoy esperando la secuela similar a un splat, pero definitivamente creo que la opción de tenerlo como primer personaje es genial. Claro que es diferente entre interactivo y script, pero eso es consistente con lo que ya es PowerShell.

La única pregunta que tengo es si esto debe ocultarse detrás de una bandera experimental. Si las pruebas son suficientes, ¿por qué hacerlo experimental en absoluto, ya que no afecta ninguna funcionalidad existente? ¿Pensamientos?

No sé por qué el equipo de MSFT es tan pasivo la última vez, pero si su código estará bajo una etiqueta experimental, podría revisarlo rápidamente. También podríamos habilitar la función de forma predeterminada en powershell.config.json.

es una lástima que PowerShell permita que los nombres de los comandos comiencen con "-".

Estoy totalmente de acuerdo. Creo que vale la pena discutirlo a fondo en el nuevo número. (Hay otros personajes que podríamos guardar).

"No se permite un elemento de tubería vacío", por lo que no debería haber ningún problema de compatibilidad de rotura si se utilizó una tubería para la continuación de la línea y el inicio de la siguiente línea, al mismo tiempo:

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

Lo que resuelve muchas de las quejas: sin comillas inversas, tubería al comienzo de una línea para una indicación visual de continuidad; no hay cambios en el comportamiento del indicador interactivo después de escribir la primera línea porque puede indicar si se espera una línea continua; no tiene mucha confusión con el operador reservado || porque está dividido en varias líneas; no es más mecanografiar que usar una tilde y una tubería; No es necesario que tenga problemas con una línea de comentarios en el medio según los ejemplos if/else , try/catch Jaykul.

@HumanEquivalentUnit : no puedo decir que sea un fanático de esa sugerencia porque yo, como guionista, puedo decidir que quiero eliminar las nuevas líneas dentro de una secuencia de comandos para el uso de cmdline y me quedaría con una sola línea inviable y no intuitiva que en mi opinión
parece atroz

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

Cuales

@kilasuit esa línea editada parece extraña (no me parece atroz, simplemente extraño), pero ¿es realmente diferente del código con comillas invertidas que es válido ahora, si eliminó las líneas sin eliminar la continuación de línea? ¿Sufre actualmente de ese problema con el código de comillas invertidas?

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

Si me preguntas, esa es una razón clara por la que las relaciones públicas de Kirk son bienvenidas, para ser honesto. Al no requerir tachuelas o una tubería adicional, es muy ordenado al condensar las líneas.

Se implementó la solicitud inicial.
Ahora discutimos https://github.com/PowerShell/PowerShell-RFC/pull/179