La alternativa actual obliga a los usuarios a normalizar los caminos

PowerShell ya hace el trabajo por usted y no necesita normalizar las rutas.
PowerShell es muy fácil de usar aquí: los usuarios pueden usar barras inclinadas con las que se sientan cómodos, independientemente de la plataforma.
La mejor práctica es evitar el uso de rutas literales y usar cmdlets de ruta.

La mejor práctica es evitar el uso de rutas literales y usar cmdlets de ruta.

@iSazonov Sí y no.

Claro, si está combinando segmentos de ruta, puede usar cmdlets de ruta. Pero si está escribiendo una secuencia de comandos que hace referencia a una ruta relativa con múltiples segmentos, y si tiene la intención de que su secuencia de comandos funcione en varias plataformas, no lo hará.

En la versión preliminar 3 de PowerShell 7 en Windows, la finalización con tabulación completa las rutas mediante una barra invertida. Ese es el único lugar donde creo que lo estamos haciendo mal ahora que PowerShell es multiplataforma. Debería haber al menos una opción para seleccionar el carácter separador de directorio que desea usar en Windows como parte de la finalización de tabulación: ya sea [System.IO.Path]::DirectorySeparatorChar o [System.IO.Path]::AltDirectorySeparatorChar . Dado dónde estamos hoy, sospecho que la mayoría de las personas que realizan cualquier trabajo multiplataforma querrían completar las rutas con pestañas para usar AltDirectorySeparatorChar en Windows de forma predeterminada, pero hasta donde yo sé, no hay forma de hacerlo. hacer eso .

@chriskuech : además de la finalización de las rutas con pestañas, ¿hay otros lugares en los que sienta que AltDirectorySeparatorChar no se está utilizando donde le gustaría tener una opción para que se use en lugar de DirectorySeparatorChar ? No puedo pensar en ninguno.

@KirkMunro , ¿está diciendo que hay una forma (al menos parcialmente implementada) de normalizar las rutas en PowerShell hoy? Si es así, ¿funcionará en la versión 6.x más reciente? Los casos de uso con los que tenía problemas eran las variables automáticas y los comandos *-Path .

@iSazonov , la solución propuesta no habría funcionado para mi escenario porque generé una lista de rutas en Windows, generé una lista de rutas en Linux, luego intenté compararlas, lo que falló debido a los separadores.

Las variables automáticas carecen constantemente de un separador de directorio final, por lo que PowerShell permite crear rutas con literales. Ex:

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

Creo que esto es mucho más claro que

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

así que espero que pueda funcionar en el futuro, aunque no por defecto.

@chriskuech mi hábito personal se ha convertido en algo como:

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

Es un poco más claro, pero sí, no es perfecto.

Join-Path tiene AdditionalChildPath que aceptan arreglos de cadenas.

@chriskuech Gracias por la información adicional.

No estaba sugiriendo que PowerShell admita parcialmente la normalización de rutas. Simplemente estaba diciendo que personalmente no me gusta que la finalización de la pestaña use una barra diagonal inversa de forma predeterminada en Windows y una barra diagonal de forma predeterminada en Linux o macOS.

Si pudiera ajustar alguna configuración para cambiar eso, de modo que la barra inclinada se use incluso en las rutas de Windows de forma predeterminada, haría ese cambio, y este es un lugar donde creo que puede haber una oportunidad para hacer que PowerShell multiplataforma funcione más fácilmente. Join-Path también usa [System.IO.Path]::DirectorySeparatorChar como separador de ruta. Idealmente, si hubiera una configuración para establecer el separador de ruta deseado al escribir scripts (porque deberíamos poder escribir scripts fácilmente de la manera que queramos, independientemente de la plataforma en la que elijamos escribirlos), se reflejaría en la finalización de ambas pestañas de caminos y Join-Path también.

Dejando de lado esas necesidades personales, me pregunto si un cmdlet Compare-Path sería útil. Podría normalizar los separadores de ruta e incluso comparar rutas absolutas con rutas relativas resolviendo rutas relativas antes de realizar la comparación si una de las rutas es absoluta.

Bueno, obtenemos una normalización _específica de la plataforma_ en Convert-Path y Resolve-Path :

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

Entonces, tal vez como una alternativa a la introducción de un cmdlet Compare-Path , Convert-Path y Resolve-Path podrían extenderse para admitir un conmutador -UseSlash (nombre negociable).

Por separado y de manera complementaria, el mecanismo de preferencia de suscripción para usar / en Windows que Kirk sugiere también podría aplicarse a Convert-Path y Resolve-Path (además de completar con tabulación y Join-Path ).

El problema en este momento es que Convert-Path y Resolve-Path solo funcionan con rutas _existentes_, pero eso es algo que vale la pena cambiar por derecho propio, como sugirió @jaykul hace muuuucho tiempo - ver #2993

Creo que sería bueno si la finalización de la ruta usara el separador de ruta que aparece explícitamente en el texto de finalización, y si no hay ninguno, entonces utilice de forma predeterminada el separador nativo de la plataforma.

Entonces, en Windows, c:\w se completa en c:\Windows\ y c:/w se completa en 'c:/Windows/'.

Creo que esto cubriría la mayoría de las molestias sin requerir una opción de configuración, y en realidad es preferible porque ocasionalmente puede necesitar la otra forma por cualquier motivo.

@lzybkr , me gusta la idea, también a la luz de una preocupación con respecto a una solución basada en variables de configuración/preferencia que olvidé mencionar: el problema de alcance; con el alcance _dynamic_ habitual, el código que hace suposiciones fijas sobre los separadores de ruta puede romperse (que tiene ecos de https://github.com/PowerShell/PowerShell-RFC/issues/7).

@lzybkr y cuando se usan ambas barras? C:\Program Files/A -> ?

Tantas opciones: aleatorias, alternar cada una, siempre barra inclinada b/c es el único separador de ruta verdadero, etc.

Más en serio, tal vez solo elija el último que se usó, que probablemente haya sido escrito por el usuario, mientras que otros podrían no serlo.

@lzybkr : Sin embargo, hay una trampa:

Si comienza _sin_ un separador de ruta, para hacer referencia a un archivo/carpeta en el _directorio actual_, PowerShell tendrá que elegir por usted, al menos según el algoritmo de finalización actual que se expande a .\<filename> o ./<filename> / .\<folder>\ o ./<folder>/ , según la plataforma.

Para _archivos_ como _argumentos_, podríamos eludir ese problema expandiendo fil a solo file , por ejemplo (sin el prefijo .\ / ./ ).

Sin embargo:

• para _ejecutables_ , el prefijo .\ / ./ agregado automáticamente es una conveniencia valiosa si la intención es ejecutar un script ubicado en el directorio actual.

• para _directorios_, de manera similar, expandirse a algo con un _separador de ruta final_ ( <folder>\ o <folder>/ ) también es valioso.

En ambos casos, no hay ninguna acción del usuario que implique el separador preferido.

Dicho esto, tal vez la solución sea: si desea controlar el separador, _comience manualmente con_ ./ o .\ y haga que la terminación de pestañas respete eso.

Este problema se ha marcado como respondido y no ha tenido actividad durante 1 día . Se ha cerrado por motivos de limpieza.

@iSazonov : esto no está realmente respondido, y debe reabrirse para permitir que la discusión en curso continúe resolviendo esto. El OP ni siquiera ha tenido la oportunidad de responder a las preguntas que le hicieron.

Creo que me dirijo todas las preguntas a mí, pero avísame si no lo hice. Yo tampoco estoy seguro de por qué este problema está cerrado. No fue pensado como un hilo de discusión, sino como una solicitud de función.

El problema de raíz en cuestión:

• ¿Debe una herramienta multiplataforma tener un comportamiento no multiplataforma de forma predeterminada?
• Si es así, ¿debería haber una manera de ejecutar PowerShell globalmente en un modo "multiplataforma"?

Creo que obligar a los desarrolladores a normalizar manualmente las cadenas con cmdlets es definitivamente un paso en falso. No veo ningún escenario en el que el uso / de manera predeterminada cause problemas en Windows porque PowerShell, como se mencionó anteriormente, es muy bueno para manejar ambos tipos de barras inclinadas. A menos que alguien pueda proporcionar situaciones convincentes en las que esto podría causar un error, ¿por qué no usar / de forma predeterminada? Quizás este problema deba trasladarse a un RFC.

A medida que más personas migran a la nube, más y más personas desarrollan código de PowerShell en Windows y lo ejecutan en Linux. Sin duda, habrá un punto en el futuro (si aún no ha pasado) en el que la cantidad de usuarios que prefieran un verdadero comportamiento multiplataforma supere a cualquiera que esté convencido de mantener \ en Windows.

@chriskuech : Mi error, no te planteé la pregunta específicamente. Me preguntaba si crees que un cmdlet Conpare-Path te ayudaría. Sin embargo, aparte de esa pregunta, también me gustaría ver opciones de normalización.

@KirkMunro No estoy seguro de que Compare-Path ayude, porque en el caso de uso original (comparando rutas en Linux y Windows), el sistema de archivos raíz es diferente, así que tengo que llamar a Resolve-Path -Relative . En ese punto, el caso de uso de comparación es solo una línea: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

Sin embargo, dudo mucho en respaldar cualquier solución basada en cmdlet, ya que no resuelve el problema raíz y no permitirá la interpolación de cadenas para rutas o requerirá cambios de código en cada definición de cadena de ruta. Específicamente, Compare-Path no arreglará todas mis rutas registradas con barras inclinadas mixtas.

@KirkMunro @mklement0 El problema no está bloqueado y todos pueden extraer comentarios.
Tenemos muchos problemas sin nuevos comentarios y avances. El estado abierto ha perdido su significado.
Como mantenedor, tengo la intención de ser más exigente para alentar las discusiones a fin de que se conviertan en especificaciones más rigurosas que puedan convertirse fácilmente en relaciones públicas.
En cuanto al problema, se vuelve infinito: la solicitud inicial fue "usar barra diagonal en Windows", luego "comparar rutas". ¿Lo que sigue? ¿Remoto? Está abierto para continuar, pero estará cerrado.
Si bien solo había una propuesta real de Jason (para mejorar la finalización) y pudimos abrir un problema de seguimiento y cerrarlo mediante relaciones públicas reales.

Para ser claros, el problema sigue siendo "usar barra inclinada en Windows". "Comparar caminos" solo se mencionó como uno (de múltiples) ejemplos motivadores.

Propuesta
Implemente un verdadero comportamiento multiplataforma, donde el delimitador de ruta predeterminado es / en todas las plataformas a menos que el usuario esté completando con tabulación una ruta que ya contiene \ . Espero que esto esté oculto como una función experimental por ahora, pero al menos debería poder habilitar una función de "maximizar el comportamiento multiplataforma" en mi código para optimizar la experiencia de desarrollo de los desarrolladores de Windows que apuntan a Linux.

Si esto no es razonable, me gustaría saber por qué y si hay documentación que guíe cuando el diseño de PowerShell difiere entre plataformas.

@iSazonov : Los mantenedores del repositorio de PS no deberían desdeñar los problemas de los usuarios sin discutirlos. Originalmente respondió sin tomarse el tiempo para comprender las necesidades del OP, marcó el problema como respondido, pero el problema no se publicó como una pregunta, se publicó como una solicitud de función y, como se puede ver en la discusión, es claramente no "respondió".

El estado abierto ha perdido su significado.

¿Quien dice? Eso no es absolutamente cierto. Un asunto abierto está abierto y un asunto cerrado está cerrado. Esas dos distinciones tienen un significado muy claro. Solo miro temas cerrados si son míos y quiero volver a revisar algo. En raras ocasiones, puedo ir a buscar temas cerrados para discusiones sobre un tema determinado. Pero el 90% o más de mi tiempo en problemas está en problemas abiertos, como debería ser. Lo único que borra la línea entre los dos y hace que los problemas abiertos pierdan su significado es cerrarlos sumariamente antes de que se resuelvan, como lo ha hecho con este problema.

(La discusión) está abierta a continuar pero se cerrará.

Con base en este enfoque de gestión de problemas, está obligando a las personas a perder la distinción entre abiertos y cerrados, de modo que tienen que buscar todos los problemas en lugar de centrarse en los problemas abiertos, lo que significa verificar los problemas abiertos de 2K más los problemas cerrados de 4K. para discusiones relevantes para ellos en lugar de solo enfocarse en los temas abiertos. Esa es una estrategia de gestión de problemas rota y defectuosa.

En cuanto al problema, se vuelve infinito: la solicitud inicial fue "usar barra diagonal en Windows", luego "comparar rutas". ¿Lo que sigue? ¿Remoto?

Eso es ridículo. La discusión se centra en tratar con Windows que tiene una barra invertida como valor predeterminado cuando escribe scripts para plataformas cruzadas. Se ha mantenido centrado en ese tema. Estás tratando de hacer que suene como si no estuviera enfocado en absoluto.

@iSazonov , estoy de acuerdo en que hay demasiados problemas abiertos; sin embargo, el hecho de que haya demasiados temas abiertos no significa que debamos ser desdeñosos y cerrar la conversación prematuramente sobre temas nuevos. Debemos continuar alentando los comentarios y estar abiertos a la discusión sobre PowerShell en los problemas abiertos, y solo cerrarlos una vez que estén realmente resueltos. El volumen de temas abiertos debe tratarse de manera diferente.

¿Usuarios leales de Linux? Consejo incomprensible.
Puedes convencer a Microsoft. Pídales que usen barras invertidas como rutas de archivos del sistema.

Me gustaría comentar aquí que hay casos de uso en los que se necesitan rutas literales con barras diagonales, incluso en Windows.

Solo estaba escribiendo un script en el que usaba las API de .net para manipular y crear archivos zip. Agregar entradas al archivo zip con esta API:

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

En este caso particular, $entry es una ruta dentro del archivo zip. Si simplemente paso la ruta de Windows tal como la devuelven varios cmdlets de ruta, todas las utilidades de compresión del planeta arrojarán advertencias acerca de que mi archivo comprimido tiene barras inclinadas incorrectas.

Además, como usuario y desarrollador de Linux desde hace mucho tiempo, me encanta PowerShell y me he divertido mucho aprendiendo. También me he divertido jugando con mi nuevo núcleo de servidor de Windows a través de ssh en powershell 7, y he publicado scripts que funcionan perfectamente con powershell en linux. Me sorprendió lo bien que funciona. De hecho, powershell será mi primera opción para algunos programas/scripts que quiero que sean multiplataforma.

Pero todavía me entristece ver que todas mis pestañas completadas se reescriben con barras invertidas.

Uso rutas como /users/foo/somefile en Windows todo el tiempo y eso es lo que quiero usar.

La mayoría de las API de Windows admiten barras diagonales sin problemas. Me doy cuenta de que hay algunas excepciones, con utilidades y quizás API, a saber, algunas invocaciones de cmd.exe, pero solo quiero configurar algo en mi perfil de $ para que, de forma predeterminada, todas mis rutas tengan barras inclinadas, a menos que esté usando barras invertidas explícitamente.

Esto sería inofensivo para los usuarios de Windows y los desarrolladores acostumbrados a las barras invertidas porque simplemente no usarían esta configuración y estaría desactivada de forma predeterminada. Por supuesto, pueden decidir usarlo también si, por ejemplo, deciden escribir más scripts y módulos multiplataforma.

También quiero esta configuración para mis scripts y módulos, para no tener problemas inesperados como el que mostré arriba.

Los usuarios de @iSazonov pueden usar barras con las que se sientan cómodos independientemente de la plataforma.

¿Significa esto que puedo configurar PowerShell para usar barras diagonales ya que es más cómodo para mí como usuario? Me gustaría cambiar la ruta que se muestra en el mensaje, así como la función de autocompletado de pestañas, que actualmente cambia las barras diagonales en barras invertidas.

@aaronfranke , no, actualmente no hay forma de configurar PowerShell de esta manera; Creo que lo que @iSazonov estaba tratando de decir es que cuando escribes manualmente una ruta, eres libre de elegir entre \ y / (e incluso puedes mezclarlos en una sola ruta) .

Teniendo en cuenta la versatilidad, se debe habilitar un nuevo símbolo de ruta en lugar de / y ，Los símbolos tradicionales aumentan la dificultad de conversión entre plataformas

Creo que lo que @iSazonov estaba tratando de decir es que cuando escribe manualmente una ruta, puede elegir entre y / (e incluso puede mezclarlos en una sola ruta).

Sí, es el diseño de PowerShell.

Esta no es una resolución de los problemas que se han planteado aquí, como el reemplazo forzoso de sus separadores de ruta durante la finalización, o la capacidad de configurar los cmdlets de ruta para usar el separador de ruta de su elección, en caso de que abramos problemas específicos separados para ellos. ?

@rkitover Pregunté sobre tales escenarios hace años (puede encontrar el problema) sin ninguna resolución. Esto me convence de que este es un cambio cosmético, aunque requiere mucho esfuerzo. Si está listo para invertir en esta área y obtener relaciones públicas, entonces tiene sentido abrir una nueva discusión.

CP/M y clones usan / para opciones, ejemplos: DIR/P , CMD/CECHO . Estos son comandos válidos. Si reemplazamos \ con / todas partes, me temo que podrían ocurrir malos entendidos.

1. Ya nadie usa CP/M.

2. Usar / para ambas opciones y rutas al mismo tiempo funciona bien en Windows en mis pruebas.

3. Las herramientas modernas usan - para las opciones, incluidas las herramientas de PowerShell y otras herramientas de Microsoft, como .NET. El uso / para las opciones debe mantenerse por compatibilidad con versiones anteriores, pero los usuarios no se confundirán con las herramientas modernas.

Además, me gustaría señalar que la barra diagonal / es un nombre de carácter no válido en los nombres de archivo de Win32:

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

Esencia

Caracteres no válidos para los nombres de archivo de Windows

Caracteres no válidos para los nombres de archivo de Windows. GitHub Gist: comparta instantáneamente código, notas y fragmentos.

Solo quiero señalar que comencé a usar barras diagonales solo en scripts multiplataforma, etc. y tuve un problema con los enlaces simbólicos.

Como ejemplo, ejecute

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

en Windows y no podrá abrir TestScript8.ps1 en VS Code en Windows.

@markm77 , descubrió un _error_. ¿Puede crear un nuevo problema para él ? [_actualización_: ver #13064]

No es que sea un argumento en contra de un mecanismo de suscripción por defecto a / , @aaronfranke , pero tenga en cuenta que hay algunos casos extremos en los que / en lugar de \ todavía se rompe cosas en Windows; p.ej:

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

Las comillas dobles de la ruta solo ayudan con las rutas de _directory_, curiosamente; consulte https://stackoverflow.com/a/43297482/45375 , que también muestra que la biblioteca de automatización COM de Excel no es compatible / .

Desbordamiento de pila

¿Por qué PowerShell no quiere guardar mi archivo como CSV?

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Abra el documento de Excel y extraiga la hoja de trabajo 'Sheet1' $Excel = New-Object -Com Excel.Application $Libro de trabajo...

@markm77 , descubrió un error. ¿Puede crear un nuevo problema para él?

¿Pero es esto un error de PowerShell? PowerShell crea el enlace simbólico correcto con la barra inclinada especificada como se verifica al examinar el enlace simbólico usando dir . Sin embargo, parece que un enlace simbólico creado con el tipo de barra incorrecta puede quedar inutilizable en aplicaciones como VS Code. Lo cual también es comprensible quizás.

NB: es bastante fácil solucionar este problema ejecutando convert-item en objetivos de enlaces simbólicos, lo que tiene el beneficio adicional de garantizar que los enlaces simbólicos apunten a rutas absolutas (probablemente apropiado).

NB, es bastante fácil solucionar este problema ejecutando convert-item en objetivos de enlaces simbólicos, lo que tiene el beneficio adicional de garantizar que los enlaces simbólicos apunten a rutas absolutas (probablemente apropiado).

Inapropiado, se romperá al volver a montar 😞

Inapropiado, se romperá al volver a montar 😞

Comentario justo, no vuelvo a montar (esto es para el trabajo de desarrollo local) y tengo un script para la regeneración de enlaces que puedo ejecutar en cualquier momento. join-path es obviamente la otra solución o incluso mejor sería una opción de new-item para garantizar que los enlaces sean apropiados para la plataforma.

Ver #12797

¿Pero es esto un error de PowerShell?

Si bien podría argumentar que en _Windows_ es un error de WinAPI, dado que \ y / generalmente se admiten indistintamente, definitivamente es un error en plataformas similares a Unix si hace lo contrario y pasa una ruta basada en \ como la ruta -Target ; en tales plataformas, solo / es compatible de forma nativa (solo PowerShell le permite usar \ como una alternativa, que viene con sus propios problemas - ver #9244), y es responsabilidad de PowerShell traducir algo como .\TestScript.ps1 a ./TestScript.ps1 al crear el enlace simbólico.

Solucionar esto, al hacer que PowerShell normalice la ruta para usar el separador (primario) _platform-native_, también solucionará el problema en Windows.

@iSazonov , #12797 habilitó fundamentalmente la compatibilidad con rutas _relative_ como destinos de enlaces simbólicos, pero el problema en cuestión es la falta de normalización del separador nativo de la plataforma, lo que hace que los enlaces simbólicos resultantes se rompan.

@iSazonov Consulte el n.° 13064 para conocer lo que aún no funciona a partir de PowerShell Core 7.1.0-preview.4 (que debería incluir el n.° 12797, ¿verdad)?

Gracias @mklement0 por lo que parece ser una investigación exhaustiva del comportamiento relativo de los enlaces simbólicos y la aparición del problema https://github.com/PowerShell/PowerShell/issues/13064. Tomé nota para hacer un seguimiento adicional del problema particular que tuve y esta discusión, pero de hecho parece que ha cubierto todo en https://github.com/PowerShell/PowerShell/issues/13064 y, de hecho, me enseñó cómo para escribir pruebas de PowerShell (soy nuevo en PowerShell).... ¡Saludos!

No seguí este tema en cada detalle, así que disculpe si me olvido de algo. El problema inicial era un separador de ruta estandarizado multiplataforma (potencialmente una barra diagonal). @iSazonov ahora cerró este problema. ¿Puede dar una descripción general de por qué cree que esto ya no es válido para que las personas que se suscribieron a los eventos de cierre de problemas puedan seguirlo?

Nunca fue válido, según https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 .

Algo como lo que @lzybkr propuso anteriormente sigue siendo algo perfectamente razonable, y presumiblemente fácil de implementar; recordar:

Creo que sería bueno si la finalización de la ruta usara el separador de ruta que aparece explícitamente en el texto de finalización, y si no hay ninguno, entonces utilice de forma predeterminada el separador nativo de la plataforma.

Entonces es responsabilidad del usuario evitar los - raros - casos extremos donde / todavía falla en Windows (ver arriba ).

Esto causa un verdadero dolor de cabeza cuando se ejecutan scripts wsl bash a través de powershell. Me gusta:

bash .\updateTemplate.sh

Esto debe ser autocompletado para

bash ./updateTemplate.sh

¿Hay alguna otra solución para este problema? específicamente, estaría totalmente de acuerdo si PS autocompleta la ruta con barras diagonales solo en contexto bash/WSL.

¿Hay alguna otra solución para este problema?

Crear completor personalizado para bash.

¿Hay alguna otra solución para este problema?

Crear completor personalizado para bash.

¿Cómo haces esto?

¿No tendremos más discusión sobre el cierre sin fundamento de este tema? Esta es una gran molestia para el trabajo multiplataforma. Cada vez que completo automáticamente las rutas que se envían a las herramientas multiplataforma o indirectamente a través de wsl a las herramientas de Linux, tengo que mover el cursor hacia atrás a través de toda la ruta y reemplazar individualmente cada barra invertida con una barra inclinada. Nadie debería tener que trabajar de esta manera, y realmente hace que Powershell como línea de comando sea casi insostenible.