Esto hace que el uso de rm , ls , etc. sea desagradable, ya que no se realiza el globbing:

> 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

Paja.

La sincronización de usabilidad generalmente acepta que la experiencia interactiva apesta sin los alias. En lo que no estamos de acuerdo es en qué alternativas se deberían ofrecer a los usuarios que quieran utilizar los binarios nativos por defecto. Algunas opciones que se han lanzado incluyen:

• Una variable de entorno para desactivar todos los alias que chocan con los binarios * nix
• Un solo carácter (como ^ ) que cae automáticamente en el PATH nativo
• Dígale a la gente que tiene que bash -c (muchos dijeron que son demasiados caracteres para ser utilizables)
• Dígale a la gente que tienen que proporcionar el camino completo (esta experiencia técnicamente ya funciona, pero es muy pobre)
• Sugerencia adicional: Aproveche el "subsistema de sugerencias" para decirle a la gente que es posible que hayan querido usar el comando nativo si usan conjuntos de parámetros que hacen coincidir patrones con los binarios nativos * nix. Esto solo puede funcionar cuando el comando falla ( rm -e , por ejemplo, no fallaría).

Creo que esto es algo que queremos resolver más temprano que tarde, así que lo he movido a la v0.5.0. En mi opinión, una configuración de PowerShell para cambiar de modo es el mejor primer paso.

@andschwa y por defecto sería ....?

@ favorece mi opinión _personal_: los alias de PowerShell habilitados; porque está ejecutando PowerShell.

Con el tiempo, de todos modos, vamos a querer una guía de "introducción" de inicio por primera vez para PowerShell, e indicaremos que esta es una configuración disponible.

@BrucePay ¿ alguna actualización sobre esto?

La sincronización de usabilidad de hoy reiteró que los alias deberían volver a ingresar (la canalización a sort es otro punto de datos para tener una experiencia de PS totalmente rota).

Dejar a Bruce como asignado para determinar el mejor camino a seguir con las mitigaciones anteriores. @andschwa : probablemente necesitemos a alguien más asignado para hacer el trabajo para volver a poner los alias.

Acabo de tener una conversación con @jpsnover y está muy claro que no estamos poniendo alias espalda. Deberíamos crear el archivo de la bandeja aliases.ps1 entrada

Probablemente valga la pena señalar que ls en bash generalmente no es simplemente ls , es un alias con algunos argumentos predeterminados, y quizás el más notable se genere usando color.

Los alias de PowerShell no funcionan en absoluto como los alias en Linux, por lo que necesitaríamos definir ls como una función o mejorar nuestros alias para que funcionen más como los alias de bash.

También podría valer la pena dedicar algo de tiempo a analizar los módulos en la galería para ver cuántos no funcionarían como están con los alias eliminados; sort es especialmente preocupante.

Los alias no están disponibles hoy, y debemos asegurarnos de que para el 17 de agosto tengamos una discusión saludable sobre los pros / contras de las situaciones de alias para que la gente se una.

Parece que tenemos una historia, cerrando el tema.

Mi 2p en esto: una nueva variable de configuración de PowerShell similar a $ PSModuleAutoLoadingPreference que se introdujo en PSv3 permitiría que el usuario final lo controle en sus perfiles (también podría armar un ejemplo simple que muestre algunos comandos ejecutándose con y sin PS Alias ​​como bueno

El nombre sugerente $ PSUsePowerShellAliases y si no se establece explícitamente en verdadero (dentro del perfil o de forma interactiva), se utilizarían los alias estándar * nix.
Creo que esto probablemente también brindaría una mejor experiencia de usuario para aquellos que ahora pueden decidir probar el agua con PowerShell que no lo habrían hecho antes, ya que no les quita lo que saben, pero permite a aquellos de nosotros que conocemos la forma de PS, la capacidad. para hacerlo también.

no quitando lo que saben

Absolutamente. Si tiene que haber un compromiso, entonces debería estar a favor de los usuarios de Linux Bash, es decir, posibles nuevos usuarios de PowerShell. Los fieles de PowerShell existentes pueden recrear sus alias * nix con bastante facilidad o, mejor aún, deshacerse de esos alias.

De hecho, ahora que tenemos PowerShell en Linux, me gustaría ver que los alias * nix incorporados se eliminen de todas las versiones del sistema operativo de PowerShell Core, si aún no lo han hecho. Eso dejaría alias integrados que coinciden con los comandos de PowerShell integrados y no intentan "engañarlo".

Soy un fanático de eliminar los alias comunes de ps en Linux de forma predeterminada; no soy un fanático de "arreglar" esto en Windows como sugiere Keith. Mi argumento a favor de esto es que si gana un usuario de Linux para PowerShell y luego decide probarlo también en Windows, no tendrá los alias comunes.

¿Podría agregarse esto a PSReadline, la capacidad de habilitar los alias de Linux o no? Para mí, es simple arreglar mi código que usa nombres cortos para funciones. Aún así, siempre escribiré LS primero y espero que funcione como el alias de PowerShell LS para Get-ChildItem .

No dude en utilizar este número para expresar su opinión sobre cuál debería ser el comportamiento de PowerShell.

Creo que lo que @kilasuit , @rkeithhill y @ 1RedOne tocaron parece ser la mejor solución: deshabilitarlo de forma predeterminada en Linux y macOS, pero al mismo tiempo,

Los scripts existentes se pueden actualizar para verificar esta variable y deshabilitar o habilitar la opción en ese mismo momento, y es mejor que revisar un montón de código para buscar nombres cortos que no se comporten como se anticipó.

Fuera del tema: ¡más que emocionado de que PowerShell esté disponible en otras plataformas! 😄

con respecto a PSReadLine, entonces @lzybkr debería poder sugerir si esa es una posibilidad, aunque la preferiría como una Variable de PS que un requisito para PSReadLine, ya que hay personas como @juneb que no usan PSReadline en absoluto

Ciertamente podría publicar una muestra para PSReadline para reemplazar alias específicos con el cmdlet de PowerShell, se basaría en esta muestra: https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354

Dicho esto, no creo que sea una solución real ...

El mayor problema en mi mente es el conflicto entre la portabilidad del guión y la familiaridad. Proporcionamos una guía de que los scripts no deben usar alias, pero sigue siendo una práctica común. Algunos alias pueden ser más problemáticos que otros, por ejemplo, sort podría usarse más que ps o ls en scripts.

Sin duda, hemos analizado algunas opciones, como proporcionar un módulo que acaba de importar para recuperar esos alias. Pero aún no nos hemos decidido por nada y esperamos recibir más comentarios.

Reemplazar los comandos de PowerShell con ejecutables nativos sin compatibilidad con globbing definitivamente no ayudará a convencer a los chicos de bash para que usen PowerShell.

Entonces, muchachos, ¿quizás sea mejor simplemente agregar soporte de globbing a los ejecutables nativos? Eso resolverá todos los problemas y hará que PowerShell sea más útil para todos, ¿verdad? Enlace # 954.

Como usuario de * nix que casi nunca ha tocado las ventanas, me gustaría votar enérgicamente por dejar los alias. Muchos años de memoria muscular me han enseñado a usar ls , rm , etc. No quiero tener que volver a aprender mi memoria muscular (luego volver a aprenderla cada vez que termine en bash) para obtener la experiencia nativa de Powershell.

Corrígeme si me equivoco aquí, pero ¿esto es diferente para dir en Windows? En PS en Windows, dir no es dir.exe . Son Get-ChildItem . En * nix, ¿por qué ls debe ser /bin/ls lugar de Get-ChildItem ?

@Gaelan Tengo su punto, pero tenga en cuenta que no hay dir.exe archivo dir es un comando interno del procesador de comandos cmd , similar a bash incorporado. Tal vez esa sea la (única) razón por la que PowerShell no fue diseñado para llamar directamente a ese comando externo dir.exe .

@Gaelan , @ForNeVeR : Si bien los elementos integrados de cmd nunca entrarán en conflicto porque no existen como programas, existen alias de PowerShell que entran en conflicto con los ejecutables nativos, incluso en Windows.

En general, no creo que haya una forma segura de mantener los alias y no romper las cosas porque teóricamente todos los alias (excepto quizás aquellos que no pueden existir en el sistema de archivos, como ? ) podrían ocultar un ejecutable nativo entonces ya no se puede llamar (al menos no por su nombre 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

Entonces, la única ruta _safe_ sería no tener alias en absoluto, lo que frustra el propósito. Y sin duda, los alias predeterminados son los más convenientes. En realidad, no tengo una buena respuesta aquí.

Personalmente, preferiría que se dejaran los alias. Por lo general, están ahí para hacer que la navegación y el uso general del shell sean más rápidos y cómodos. Eliminarlos degradará la experiencia de usar PowerShell.

Apoyo la idea de posiblemente agregar una forma de indicar que está llamando al binario integrado de Linux. ¿Quizás incluso como una preferencia de perfil?

Si miras el historial aquí, he sugerido lo que creo que es la mejor solución desde una perspectiva de UX para alias que se asignan a comandos equivalentes que no son de Windows

Este es un problema de PowerShell de larga data. Me quejo de que no tiene un comando comparable a dir cmd o incluso a ls . La respuesta, cada vez, es "¡pero hay un alias!".

Los alias no son y nunca han sido una solución a este problema. Los alias dir y ls no proporcionan la funcionalidad que proporcionan dir y ls . Lo mismo es cierto para los alias wget y curl .

Es necesario repensar todo el enfoque de los alias y eso significará cambios importantes.

¿Por qué los alias definidos por el sistema no pueden ser ciudadanos de segunda clase para los binarios en PATH?

Yo diría que elimine todos los alias * nix en Linux, compilaciones de OS X hasta que descubra qué hacer.

Editar: Gracias por aclarar que esto ya se hizo, perdón por la interrupción.

@okket que ya se ha hecho. Estamos discutiendo si es necesario cambiar algo.

Me parece que deberíamos poner todos los alias en los archivos que las personas pueden obtener en sus perfiles, y luego, proporcionar un perfil predeterminado específico del sistema ...

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

Al menos, eso sirve para recordarle a la gente que no todo el mundo tiene los mismos nombres cortos.

No olvidemos (@sleepypikachu) que los alias de PowerShell no _hacen_ nada excepto cambiar el nombre del comando y anular el orden de resolución del comando. La funcionalidad alias Bash requiere _functions_ en PowerShell.

@Gaelan, su memoria muscular le permite usar el alias, pero ¿se sentiría frustrado con los parámetros y el comportamiento que no funcionan igual que el comando real?

Ese es el problema real aquí y @DrPizza es

Entonces, hay realmente tres problemas relacionados aquí:

1. No todos los parámetros tienen alias
2. No todos los parámetros o comportamientos nativos se asignan en PowerShell CmdLet.
3. Necesita una forma de ejecutar el comando nativo si existe un alias

No creo que el número 1 sea un problema demasiado grave y empeoraría las cosas si tuvieran un alias. Dir -recurse es un parámetro más legible que dir / s de todos modos. Además, con la plataforma cruzada, hace que los scripts sean inconsistentes cuando se intenta pasar de Windows a Linux y viceversa.

2 y 3 son los más importantes. Nunca usé curl, pero sé que me encontré con limitaciones con Invoke-WebRequest que esperaría que curl pudiera hacer. (No recuerdo la parte superior de la cabeza).

A corto plazo, creo que necesita tanto una opción de configuración como una forma de llamar al comando nativo si el alias está habilitado.

Por defecto, déjelo habilitado. Esto es PowerShell ... en Linux. Debería comportarse como PowerShell para que puedan aprender qué CmdLets usar. A mi compañero de trabajo con experiencia en Linux y Perl le resultó mucho más fácil averiguar los cmds que necesitaba para que un script funcionara. Creo que fue grep, ls y man lo que fue clave para él. Usar man debería ayudarlos a descubrir cómo usar el cmd correctamente.

A largo plazo, agregue cobertura a los cmdlets nativos para tener todos los parámetros y capacidades de los comandos nativos. Esto mejora PowerShell para Windows y Linux al brindarnos opciones más poderosas. Es probable que algunos de los comportamientos deban convertirse en múltiples CmdLets y usar Objetos y Pipelines, ¡pero eso es genial! Si no hiciera eso, ¿cuál sería el objetivo de PowerShell?

Mi opinión es mantenerla como está. Sin alias en PowerShell (excepto select y etc., son obligatorios), alias en Windows PowerShell.

Proporcionar una opción es mejor, pero proporcionar todos los alias como opciones es ... bueno, no imposible.

En mi humilde opinión, tener ls alias para dir tiene sentido, ya que podría usar fácilmente Where-Object para filtrar archivos. He sido un usuario de Linux durante años y escribir dir no es tan natural como usar ls.

Me parece que la coherencia es importante. No estoy en contra de eliminar los alias de otras plataformas, pero me molesta tener una interfaz que se comporta de manera diferente según el sistema operativo. Uno de los puntos principales de tener PS ejecutándose en * nix es que es una interfaz para administrar todo. Si los alias se eliminarán de PowerShell en las plataformas recientemente admitidas, creo que se debe considerar si deben eliminarse también en Windows.

No, apoyo firmemente que PS proporcione alias de forma predeterminada, pero lo real debajo debería tener exactamente la misma funcionalidad (y tal vez compatibilidad de parámetros) con los binarios nativos originales, excepto por el soporte de escritura.
PowerShell sin tipos es inútil.

El uso de los binarios del sistema subyacente y la adopción de la filosofía de las herramientas de Unix promoverán la adopción. Como persona que hace devops en tiendas de Unix, me sorprendió gratamente descubrir que los binarios de Unix normales funcionaban un poco en esta implementación. Con respecto al problema del carácter *, creo que la mayoría de las personas en el lado * nix se sentirían cómodas con el uso de un carácter de escape delante del * cuando se indica * nix shell glob en lugar de lo que sea su comportamiento actual en powershell. Probablemente sería una solución aceptable para | ya que una tubería que produce un objeto en lugar de un flujo de octetos que pasan entre archivos va en contra de los estándares publicados y dificultará la adopción. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis tenga en cuenta: nadie va a eliminar tipos de PowerShell ; ya sea gci y Get-ChildItem permanece igual en Windows PowerShell y Linux PowerShell. Aquí solo estamos hablando de si un alias integrado como ls -> Get-ChildItem debería existir en Linux o no. Sus scripts no deberían llamar a ls o gci todos modos si quiere llamar a Get-ChildItem (porque no se recomienda el uso de alias en los scripts y nunca se recomienda). ls y gci son solo alias de conveniencia para el uso de la línea de comandos, y _podría_ confundir al usuario de Linux si ls repente se alias a Get-ChildItem y no a su comando nativo favorito; lo confundirá aún más si no tiene una forma concisa de llamar a este comando directamente.

Estoy para usar el comando para habilitar el alias en powershell.
Mantenga todos los alias y desaprovecharlos lentamente en Windows powershell.

Creo que usar un comando como

Enable-Alias Unix
Enable-Alias dos

Habilitar alias tiene las siguientes ventajas

1. Resuelve el problema para las personas que quieren usar curl nativo.
2. Desalienta a las personas a usar un alias en los scripts (lo que altera la legibilidad del script).
3. También es muy fácil para las personas que aman esos alias habilitarlos
4. y apenas compromete el rendimiento.

@ForNeVeR uso ls como gci todo el día porque es una letra más corto ...
Sin embargo, la introducción de este cambio (eliminar los alias de Unix-y y dos-y) es definitivamente un cambio importante (no es como curl ). Una solución "perfecta" puede ser la implementación de estos comandos en una mejora mecanografiada de las herramientas existentes.
Para los scripts, tal vez ... ¿una declaración using ?

@ForNeVeR Creo que has entendido mal a @ be5invis . Es un gran partidario de powershell. Creo que lo que quiere decir con "powershell sin tipo es inútil" es que la gente no debería usar curl nativo en powershell.

@ be5invis También creo que su idea de la compatibilidad de curl nativo es de gran alcance. La gramática de powershell no es compatible con la gramática estándar de Unix, por ejemplo, puedes hacer rm -rf en unix pero en powershell tienes que hacer rm -r -fo .
Por lo tanto, nunca alcanzará la compatibilidad de parámetros sin importar qué.

@chantisnake Entonces, ¿por qué no agregar un parámetro llamado "rf", que es igual a -recurse -force ?

@ be5invis Esto va en contra de cómo funcionan los parámetros en PowerShell. Son ortogonales y, en caso contrario, existen diferentes conjuntos de parámetros. También solo tienen nombres largos y, en lugar de nombres cortos, se pueden abreviar individualmente siempre que no sean ambiguos. En su caso, también deberá agregar un alias a ese parámetro, fr . Además, de repente, -Recurse ya no podría acortarse a -r sino que tendría que ser -re para no entrar en conflicto con el parámetro -rf .

Podría hacer la misma pregunta desde el otro lado: ¿Por qué no especificar ambos parámetros por separado? Está dispuesto a ir en contra de los principios y convenciones del código de PowerShell en gran medida solo para seguir fingiendo que todavía está trabajando con las mismas herramientas Unix, incluso si no lo está. Sin embargo, las convenciones de los parámetros GNU con sus nombres cortos y largos no son universales y muchas herramientas bien establecidas van en contra de ellas, por ejemplo, tar , o find . Sin embargo, no está en armas con sus rastreadores de errores para cambiarlos. Si bien una parte fundamental de Unix siempre ha sido que hay mil millones de programas de utilidad diferentes que funcionan cada uno de formas ligeramente diferentes, de repente tener otro de ellos (es cierto, hacer un poco más y tratar de abarcar muchas otras utilidades en sí mismo) es ¿Tan desconcertante y problemático que hay que cambiarlo? No lo creo.

Recuerde: el caparazón de su máquina es suyo. Así como las personas se alias rm a rm -i para su propia comodidad, no hay nada que le impida eliminar el alias rm y tener una función que envuelva Remove-Item llamada rm con un parámetro -rf .

Pero intentar cambiar PowerShell en su totalidad para replicar completamente cada herramienta Unix es bastante equivocado.

La funcionalidad y la salida de ls ha estado bien definida durante muchos años. El comando ls genera un flujo de octetos en un formato bien conocido. El comando ls no genera objetos DirectoryInfo y FileInfo. Tener ls emitiendo algo diferente es como mínimo confuso y posiblemente un poco engañoso.

Cuando el usuario esté listo para tener los beneficios de los objetos en la canalización, aprenderá sobre Get-ChildItem y gci. Si el usuario no quiere tener los beneficios de, o tratar con, objetos en la canalización, es mejor que use bash, ksh, csh, sh, etc.

Lo mismo puede decirse del comando DIR en Windows.

Deje que * nix sea * nix y haga que Powershell sea lo mejor posible.

@Liturgista

Cuando el usuario esté listo para tener los beneficios de los objetos en la canalización, aprenderá sobre Get-ChildItem y gci. Si el usuario no quiere tener los beneficios de, o tratar con, objetos en la canalización, es mejor que use bash, ksh, csh, sh, etc.

Esto contradice tu punto. Si las personas usan Powershell, probablemente quieran objetos en la tubería. No deberíamos hacer y luego volver a aprender los comandos básicos para aprovechar esto.

De acuerdo con @Gaelan.
Si alguien no quiere objetos, simplemente puede cambiar a bash o zsh.
Quieren los beneficios de los objetos, y poner un alias en cosas como ls a una versión compatible pero escrita les dará exactamente lo que quieren.

@Gaelan y @ be5invis , entiendo el deseo de limitar la cantidad de cambios que un usuario debe hacer para usar Powershell. Mis dedos parecen escribir ls antes de que mi cerebro siquiera les envíe una señal.

El problema es que esos comandos básicos existentes no producen objetos. El cambio real a realizar no es de ls a gci . El cambio más grande es desde el pensamiento realizado para procesar líneas de texto hasta pensar en las propiedades y los métodos que se pueden aplicar a un objeto.

Todos los usuarios tienen derecho a crear los alias que quieran. Estoy de acuerdo en que podría ser más fácil para el usuario hacer esto agregando un método y una propiedad a $ Host (System.Management.Automation.Internal.Host.InternalHost) para habilitar o deshabilitar el reemplazo del comando nativo. He visto otros, pero ¿hay una herramienta de configuración de perfil GUI incluida con Powershell?

Si alguien no quiere objetos, simplemente puede cambiar a bash o zsh.

¿Por qué PowerShell no puede proporcionar una "rampa de acceso fácil" para las personas que han usado bash durante años y luego deciden sumergirse en las aguas de PowerShell? Permítales comenzar con lo que saben y comenzar a introducir en fases las características de PowerShell (como comandos de emisión de objetos y objetos en la canalización) a medida que se sientan más cómodos usando PowerShell.

No puedo decirte cuántas veces he tenido que usar la línea "_PowerShell es un shell . Ejecutará tus utilidades nativas favoritas sin problemas_" para que la gente pase la idea de que solo pueden usar PowerShell con esos comandos que suenan divertidos. y conseguir que prueben PowerShell. PowerShell debe respetar y trabajar con las utilidades nativas populares lo mejor que pueda: punto. Después de todo, ese es uno de los trabajos principales de un "shell".

@rkeithhill Permítanme aclarar: para los usuarios que quieren usar Powershell, quieren tipos, ¿verdad? Sin embargo, sus herramientas nativas, como /bin/ls , no pueden comunicarse con tipos. Por lo tanto, al cambiar a un shell con tipo, pero sin utilidades con tipo, el cambio no tiene sentido.

Por lo tanto, los usuarios típicos de Unix pueden querer escribir el comando idéntico, pero obtener el resultado escrito directamente. Entonces hay dos opciones:

1. Proponga un protocolo IPC mecanografiado y dígale a Linus que actualice sus herramientas. No, no lo harán, ¡porque lo ha propuesto su ENEMIGO , el SEÑOR MALVADO , el destructor del mundo libre ! ¡Nos van a “abrazar, extender y extinguir”! o...
2. Alias ls a un incorporado con parámetros compatibles.

Para los usuarios que quieren usar Powershell, quieren tipos, ¿verdad?

Eventualmente, probablemente lo harán. Dicho esto, trabajo con varios desarrolladores que comencé en PowerShell simplemente vendiéndolos sobre su uso con Git y Posh-Git (algo que CMD no puede proporcionar). Rara vez canalizan algo en este punto, pero espero que lleguen allí. Ese punto es que la utilidad git.exe se comporta en PowerShell tal como se comporta en CMD. Fácil transición.

Para mí, ls (como ps, grep, sed, awk, gcc, curl, etc.) es solo otra utilidad nativa que cualquier "shell" debería poder ejecutar. Ahora, si alguien está listo y quiere el comando de emisión del objeto para listar el contenido del contenedor, puede usar Get-ChildItem o su alias gci . Si están inclinados a que nunca usarán la utilidad nativa ls , entonces pueden crear un alias ls para Get-ChildItem en su perfil.

Por cierto, no creo que sea factible intentar hacer que el parámetro Get-ChildItem compatible con ls . Se quedará colgado bastante rápido con los parámetros de PowerShell que no distinguen entre mayúsculas y minúsculas, por ejemplo, -c / -C, -d / -D, -i / -I. Y PowerShell no admite la combinación de parámetros, por ejemplo, ls -rt. Es un alcance y viola el principio Monad de PowerShell. Una tarea como la clasificación se realizaría mediante un cmdlet independiente (Sort-Object) y no mediante Get-ChildItem en sí.

@rkeithhill No voy a hacer que Get-ChildItem sea ​​compatible con ls . Estoy proponiendo otro cmdlet, puede llamarse UnixCompatibles-ls como su nombre completo, y tengo un analizador de comandos separado que acepta el sabor GNU getopt, en lugar de PowerShell.

@ be5invis ¿No es la opción más fácil en ese momento una función separada que ejecuta ls , pasándole todos sus argumentos, analiza la salida y crea objetos a partir de ellos? Un analizador de comandos completamente separado (junto con metadatos de comando completamente separados, formatear para Get-Help , ...) es un poco exagerado (aparte de replicar gran parte del funcionamiento interno de PowerShell de una manera incompatible.

Siempre habrá dos mundos separados aquí, uno nativo y otro escrito. PowerShell ya les da servicio a ambos, al poder ejecutar programas nativos y cmdlets. Personalmente, no veo ningún beneficio (solo una empresa masiva en el esfuerzo de desarrollo) al intentar agregar una capa por encima de los comandos nativos que replica sus metadatos de parámetros dentro de PowerShell. Además, ¿qué harías con tar , o find (y muchos otros programas), que AFAIK no se adhieren a las convenciones GNU? ¿Implementar todavía _otro_ analizador de comandos, junto con funciones contenedoras para llamarlos? Tenga en cuenta también que para que funcione un analizador de comandos, los argumentos del programa nativo deben analizarse dentro de PowerShell y no deben entrar en conflicto con el idioma. Algo que puede resultar difícil con cosas raras como [ .

@ygra Está bien tampoco.

Para los usuarios que quieren usar Powershell, quieren tipos, ¿verdad?

@ be5invis , quizás aquí es donde ocurre un poco de desconexión. No, no quieren tipos. El usuario quiere hacer su trabajo o jugar. El usuario sabe que ls produce un flujo de texto.

¿Es UnixCompatibles un verbo? ¿Cambiaría esto el script $ PROFILE del usuario de forma permanente o solo para esta sesión? No quisiera que Get-ChildItem sea compatible con ls. Sea ls ls y haga lo que hace ls . Parece que esto le daría al usuario la opción de reemplazar ls con Get-ChildItem . Esta bien. No estoy seguro de querer eso, pero para aquellos que lo quieren, está bien.

@Liturgist Creo que lo que quiere decir tomó la molestia de cambiarse a Powershell (en lugar de quedarse con Bash), es porque quieren algo que Powershell proporciona. Si la gente quisiera un flujo de texto de ls , (en Linux o macOS) nunca se habrían molestado con Powershell.

@Gaelan ¿Entonces no debería usar PowerShell si necesito usar gcc o git? ¿Qué tiene de malo dejar que las personas decidan si quieren texto (ls) u objetos (gci)? Hay más razones para usar PowerShell además de su naturaleza orientada a objetos, por muy poderosa que sea. Demonios, prefiero usar PowerShell solo para sus declaraciones de flujo de control similares a C / C # (frente a if / fi y switch case / esac) y su sistema de tipos adecuado (donde los números son números y no cadenas).

@rkeithhill

Entonces, ¿no debería usar PowerShell si necesito usar gcc o git?

En un sistema * nix, si los usuarios solo quisieran usar el shell para gcc o git, no se molestarían con PowerShell, porque el shell que viene con su sistema operativo lo hace perfectamente bien.

Diablos, prefiero usar PowerShell solo para sus declaraciones de flujo de control similares a C / C # (frente a if / fi y switch case / esac)

Quizás si alguien ya estuviera usando PowerShell lo preferiría por eso, pero dudo que alguien instale PS solo por eso.

su sistema de tipos adecuado (donde los números son números y no cadenas)

/bin/ls tampoco funciona con el sistema de tipos: si ejecuto ls -l , obtendré los tamaños de archivo como una cadena en lugar de un número PS adecuado.

Siento que las razones por las que un nuevo usuario cambiaría a PS en * nix giran principalmente en torno al OO y al sistema de tipos. Deberíamos hacer que sea lo más fácil posible para los nuevos usuarios comenzar con PS; si veo algo sobre PS, trato de verificarlo, solo para descubrir que necesito volver a aprender todo sobre la línea de comando para usarlo, probablemente lo haría Sería mucho menos probable que me molestara en aprenderlo que si pudiera encender PS, escribir ls e inmediatamente ver el sistema de tipos en acción. Sí, podría usar alias, pero si solo estoy probando PS en unos minutos libres, es poco probable que quiera hacer mucha configuración antes de saltar y comenzar a jugar.

En un sistema * nix, si los usuarios solo quisieran usar el shell para gcc o git, no se molestarían con PowerShell, porque el shell que viene con su sistema operativo lo hace perfectamente bien.

Quizás si alguien ya estuviera usando PowerShell lo preferiría por eso, pero dudo que alguien instale PS solo por eso.

Lo siento, pero estoy totalmente en desacuerdo. Como un usuario de Linux, quiero usar PowerShell en lugar de concha que venía con mi sistema operativo. Para todo. Porque es genial, ya sabes :)

Diablos, incluso estoy empaquetando PowerShell para NixOS en este momento solo para usarlo para todo.

Tenga en cuenta que nuestros usuarios objetivo no son solo usuarios nativos de Unix que accidentalmente usan Windows + PowerShell, sino también usuarios de Windows que accidentalmente usan Unix + PowerShell;)

Un solo carácter (como ^) que cae automáticamente en el PATH nativo

También preferiría mantener los alias compatibles en todos los sistemas operativos siempre que sean válidos en estas plataformas y usar un carácter de escape (como ^ls ) para obtener un acceso implícito a los comandos nativos, como lo sugiere @joeyaiello
No estoy familiarizado con toda la filosofía de PowersShell, pero ¿qué podría estar mal con este enfoque?

En realidad, un punto más por usar un escape de un solo carácter: bash ya lo hace. https://twitter.com/climagic/status/806536501232340992

\ls ignora todos los alias.

¿La respuesta a los alias se resuelve habilitando WSL (Subsistema de Windows para Linux)? Esto proporcionará comandos nativos sed, awk, ls, etc. en un shell bash.

Si bien todavía es un código beta para Windows 10, seguramente llegará y estará disponible en Server 2016 y 2012.

@Liturgist Actualmente, WSL es un entorno muy separado de PowerShell. Los comandos no se pueden llamar desde una sesión de PowerShell. Además, es probable que muchos usuarios actuales de Windows PowerShell consideren esto como una regresión, ya que muchos scripts se romperían si recibieran el resultado de, digamos, GNU ls lugar de ls -> Get-ChildItem . Si bien el uso de alias nunca se recomendó en los scripts, el hecho es que se han usado y la rotura causaría dificultades a muchas personas.

@Liturgist : @bgshacklett está aquí. El problema no es que algo suceda cuando escribe ls , la pregunta es qué parámetros espera al usar eso, y si la salida emitida es consumible de una manera orientada a objetos por otros cmdlets de PowerShell (es decir, ls | Where-Object Name -like *foo* no funcionará si está utilizando el WSL ls ).

Se ha solucionado el problema original de los alias en conflicto con los cmds nativos. Si es necesario tener la capacidad de volver a agregar alias populares de Windows PowerShell, eso debería ser un problema aparte.

Se abrió https://github.com/PowerShell/PowerShell/issues/3610 para capturar el problema secundario