Powershell: Cree pwsh como un nombre más corto para llamar a powershell.exe

Me gustaría tener un alias corto también, pero esta es la razón por que no nos vamos con posh cuando fuimos primero en salir (hablamos de ello en detalle). También parece ser un paquete actualizado.

Abierto a otras sugerencias, pero se han tomado la mayoría de las obvias * sh. Después de la única cosa de wget / curl alias, me gustaría evitar chocar con otros paquetes, incluso si son menos comunes.

No estoy muy loco por toda esta idea, pero ¿qué tal pwsh ?

Nunca me ha gustado lo elegante como un acortamiento de powershell. pwsh parece mejor, pero una búsqueda rápida en Internet plantea algunos problemas posibles. si vamos a hacer esto, sugeriría lo más corto posible, así que ¿qué pasa con ps?

OK, olvídalo, me acabo de dar cuenta de que ps es un alias para get-process. eso sería demasiado confuso

Estoy teniendo un fuerte deja vu ahora mismo. 😉

Aprecio la legibilidad de PowerShell (cuando no utilizo alias), por lo que ejecutar powershell funciona bien para mí.

ps es un comando existente en Linux.

Algunas otras ideas son: pscmd , psc , monad , psh , pshell

Definitivamente hay rendimientos decrecientes con estos nombres, sin embargo, sobre si realmente guardan algo o simplemente agregan confusión innecesaria si están disponibles.

CoreSh , pcs , psc

Lástima que se haya tomado mosh . psh está tomado. [pshell] devuelve muchos hits. Curiosamente, una búsqueda de msh tanto en Bing como en Google arroja muchos resultados para PowerShell (llamándolo Microsoft Shell), aunque existe un msh en Unix (quizás no se use mucho)

😄 S #, P #

@ PowerShell / powershell-Committee discutió esto y está abierto a tener un nombre de enlace simbólico más corto, pero no podemos ocuparnos de nadie que ya exista. prsh parece estar bien.

¡Espera espera! Lo tengo: ^sh - ¿o era **sh ? (jk).

prsh parece razonable - más fácil de escribir que pwsh , por ejemplo, aunque pwrsh - a pesar de ser 1 carácter. más largo - también vale la pena considerarlo, dado que "pwr" es una abreviatura conocida de "potencia".

Otra opción, posiblemente _complementaria_: proporcione una _ variable automática_ cuyo valor _invariablemente_ refleje la misma ruta del binario que inició la sesión actual.

bash tiene $BASH para eso.

La ventaja de este enfoque es que es impermeable a las variaciones / manipulaciones de $env:PATH .

Ya tenemos $PSHOME - posiblemente, algo como $PS no es demasiado exagerado.

Dicho esto, esto se relaciona con la discusión sobre no contaminar el espacio de nombres global con variables automáticas - vea # 4216.

.Net Core, CoreFX, CoreCLR, PowerShell Core: podríamos considerar "core" como base.

pscore parece bien incluso si no termina con sh aunque otros miembros del Comité lo vetaron

pscore o coreps - LGTM.

Podemos recordar monad y msh (mencionados anteriormente).

Me gusta pwrsh lo mejor hasta ahora. pscore tampoco está mal, aunque se está volviendo un poco alargado con 6 caracteres. Probablemente lo ideal sea cuatro o menos caracteres, pero podría vivir con los 5 caracteres requeridos por pwrsh .

Mi preocupación por incorporar la palabra "núcleo" es que no contiene información útil en plataformas Unix, donde no hay otra edición de la que deba distinguirse.

@rkeithhill ¿qué tal pscx , ja! Experiencia de PowerShell Core. Sin embargo, eso me hizo pensar en otro pscsh , PowerShell Core Shell.

Yo mismo estoy dividido por algunos de los mismos nombres. Me gusta la legibilidad de pwrsh y pscore pero estoy de acuerdo en que 5 caracteres es el límite. 5 caracteres cubren la primera palabra power y más que eso, también puede escribir el texto completo. monad es un gran huevo de Pascua y legible, pero confuso para aquellos que no conocen los antecedentes de PowerShell. Los 4 caracteres prsh también funcionan bien.

Sería bueno tener una lista final de nombres que se puedan usar y hacer una encuesta oficial como hizo el equipo de Edge. Si hay eventos oficiales o de la Comunidad de PS próximos, se pueden proporcionar enlaces a la encuesta para intentar llegar a una audiencia más amplia.

@ dragonwolf83 :

pscsh está peligrosamente cerca de csh , una asociación que debemos evitar.

Nuevamente, no veo ningún beneficio en incluir la palabra "core", especialmente si existe la posibilidad de que las ediciones se unifiquen algún día (y en _Windows_, la gente parece haber vivido cómodamente sin un nombre corto para _Windows PowerShell_ durante una buena década) .

Se acordó la oscuridad de monad .

Mi voto personal es por pwsh , prsh o pwrsh .

PD: En caso de que _Windows PowerShell_ también necesite un nombre corto, simplemente prefijar w podría ser la solución, aunque entre mis favoritos que realmente solo (razonablemente) sale del teclado como wprsh , así que en el escenario de dos ediciones de nombre corto mi voto es para el par prsh / wprsh .

Mi preocupación por incorporar la palabra "núcleo" es que no contiene información útil en plataformas Unix, donde no hay otra edición de la que deba distinguirse.

:-) ¿Deberíamos cambiar el nombre de .Net Core?

@iSazonov : ¿Deberíamos cambiar el nombre de Windows PowerShell a "Windows PowerShell .NET Framework [FullCLR]?"

Yo votaría por psh : el proyecto que citas como una colisión no ha sido lanzado en 10 años y nunca estuvo en repositorios de paquetes en ningún caso.

@Jaykul :

psh ? No sé, necesita más "núcleo", si me preguntas.

Bromas aparte: excelente punto sobre el estado del proyecto y su ausencia en los repositorios de paquetes.

psh tiene mi voto (y wpsh para Windows PowerShell).

(Se pronuncia 'pshaw' y 'latigazo cervical', respectivamente).

psh tiene mi voto (y wpsh para Windows PowerShell).
(Se pronuncia 'pshaw' y 'latigazo cervical', respectivamente).

¿Estás seguro de que no podemos usar posh en Windows y pronunciarlos pish posh? 🤡

¡Pish-tosh! Eso es una mezcolanza para toda la mishpocha. 🤡

Yo votaría por psh: el proyecto que citas como una colisión no ha tenido un lanzamiento en 10 años y nunca estuvo en repositorios de paquetes en ningún caso.

¿No tiene problemas de redacción?

¿No tienes problemas de derechos de autor?

Espero que alguien que realmente _ sabe_ intervenga, pero mi _ conjetura_ es que esto no será una preocupación por 2 razones:

• psh no es el nombre oficial del producto, solo un inicialismo (más vagamente hablando, un acrónimo) que es simplemente una ayuda técnica (aunque en el uso popular puede eventualmente convertirse en una abreviatura común para el nombre completo del producto; es_ posible a iniciales / acrónimos de marcas registradas).

• Los problemas de marcas comerciales a menudo tienen que ver con la probabilidad de _confusión_ con las marcas comerciales existentes, y por lo que hemos visto aquí, al menos en el espacio del software no parece haber colisiones (no creo que el creador del prácticamente desaparecido psh repo le importará o incluso tiene un caso legal).

En caso de que alguien quiera experimentar / necesite una solución provisional:

Aquí hay una solución de todos los alias que define los alias tanto dentro como fuera de PowerShell, en todas las plataformas compatibles: psh para PS Core y wpsh para Windows PowerShell.

• Ejecute lo siguiente UNA VEZ para configurar alias FUERA de PowerShell (por cmd.exe en Windows, por bash en Unix):

  # Note: 
  #   * On Unix, this will define alias `psh` for *interactive* Bash sessions,
  #     via initialization file ~/.bashrc (Linux) or ~/.bash_profile (macOS).
  #   * On Windows, this defines doskey.exe-based aliases `psh` and `wpsh`
  #     via registry key [HKEY_CURRENT_USER\Software\Microsoft\Command Processor],
  #     value 'AutoRun', and even though *any* cmd.exe instance will run
  #     these alias definitions, they only work in *interactive* ones.
  #     Note that both aliases open a new window.
if ($env:OS -eq 'Windows_NT') {
  $cmd = 'doskey wpsh=start powershell.exe & doskey psh=powershell.exe -nologo -command "psh"'
  $currVal =  try { Get-ItemPropertyValue 'HKCU:\Software\Microsoft\Command Processor' AutoRun } catch {}
  if (-not (Select-String -Quiet -SimpleMatch -Pattern "$cmd" -InputObject $currVal)) {
    if ($currVal) { $cmd += " & $currVal" }
    Set-ItemProperty 'HKCU:\Software\Microsoft\Command Processor' AutoRun $cmd
  }
} else {
  $cmd = 'alias psh=powershell'
  $initFile = ("$HOME/.bashrc", "$HOME/.bash_profile")[(uname) -eq 'Darwin']
  if (-not (Select-String -Quiet -LiteralPath $initFile -Pattern "^\s*$cmd\b")) {
    Add-Content -LiteralPath $initFile -Encoding utf8 "`n$cmd"
  }
}

• Ponga lo siguiente en su $PROFILE para definir los mismos alias dentro de PowerShell; funciona tanto en PS Core como en Windows PS:

  # ===
  # Portable alias definitions for PowerShell Core (`psh`) 
  # and, on Windows, for Windows PowerShell (`wpsh`) too.
  #
  # Place them in $PROFILE.
  #
  # * On Unix, invoking `psh` always runs the new instance in the current terminal window.
  # * On Windows, only invoking the same edition runs in the current console window.
  #   Invoking the respective other edition opens a new window; if you also
  #   pass a command, add -NoExit to keep the new window open.
  #
  # ===
  if ($env:OS -eq 'Windows_NT') { # on Windows
    if ($PSVersionTable.PSEdition -eq 'Core') { # running in a PS Core session
      # PS Core alias: Invoke the same binary that started the current session.
      Set-Alias psh "$PSHOME\powershell.exe"
      # Windows PowerShell alias
      function wpsh {
        # Assume a fixed location in SYSTEM32.
        $exe = "$env:SYSTEMROOT\System32\WindowsPowerShell\v1.0\powershell.exe"
        $psModulePathSav = $env:PSModulePath
        try {
          # Note: We must remove all *\PowerShell\* entries from $env:PSModulePath, because they are Core-specific
          #       and interfere with module loading in Windows PowerShell.
          # Note that Start-Process -UseNewEnvironment is NOT an option: see https://github.com/PowerShell/PowerShell/issues/3545
          $env:PSModulePath = (($env:PSModulePath -split ';') -notmatch '[/\\]PowerShell[/\\]') -join ';'
          # Start Windows PowerShell in a new window.
          $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
          Start-Process $exe <strong i="18">@htArgs</strong>
        } finally {
          $env:PSModulePath = $psModulePathSav
        }
      }
    } else { # running in a Windows PowerShell session
      # PS Core alias:
      Function psh {
        # Given that the PS Core *.exe is not in $env:PATH as of PowerShell Core v6.0.0-beta.5, determine its location.
        # Since multiple versions may be installed, find the highest version installed.
        # Unfortunately on PSv5.1- [semver] ([System.Management.Automation.SemanticVersion]) is not available, so we fall back to the *.exe files' last-write timestamp.
        # WISHFUL THINKING: Set-Alias psh ((Get-ChildItem -Directory $env:ProgramFiles\PowerShell | Sort-Object -Descending { [semver] $_.Name })[0].FullName + '\powershell.exe')
        $exe = ((Get-ChildItem -File $env:ProgramFiles\PowerShell\*\powershell.exe | Sort-Object -Descending LastWriteTime)[0].FullName)
        # Note: The Core-specific module directories are automatically added to $env:PSModulePath, so no other action is required.
        # Start PS Core in a new window.
        $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
        Start-Process $exe <strong i="19">@htArgs</strong>
      }
      # Windows PowerShell alias: invoke the same executable that started the current session.
      Set-Alias wpsh "$PSHOME\powershell.exe"
    }
  } else { # on Unix (Linux, macOS)
    # Simply invoke the same binary that started the current session.
    Set-Alias psh "$PSHOME/powershell"
  }

¿Qué pasa con Paua ? Esta es una referencia a la hermosa concha de paua (una concha marina de Nueva Zelanda). De lo contrario, creo que psh es bueno.

¿Vende conchas marinas de la costa (de Nueva Zelanda)? (Es broma. Hermosa de hecho).

Descargo de responsabilidad: lo siguiente solo es de interés para los lingüistas [aficionados].

Fonéticamente, paua solo funciona para dialectos no róticos del inglés (por ejemplo, Reino Unido, Nueva Zelanda, Australia).

Y bostonianos.

@ PowerShell / powershell-Committee debería cerrar esto para beta.8

¿Qué tal Posh6?

¿Qué tal Posh6?

Parece que eso quedaría desactualizado más rápido que poner un número de versión en una extensión de archivo ...;)

Sí, pero un script de shell que lo inicie sabrá qué versión está ejecutando.

Aunque me gusta posh , creo que la principal preocupación es que existe un paquete para Linux llamado Posh, así que para evitar otro incidente curl , creo que la siguiente mejor opción es pwsh

Me gusta pwsh . Hubiera sido bueno tenerlo hace 10 años. Extraño msh .

Voto por psh .
gnp / psh no se ha comprometido en casi 5 años. También puede ser abandonware.

Odio decirlo, pero esta es una de esas cosas en las que podría ser demasiado difícil lograr un consenso sólido. : \

En este punto, para cerrar las cosas y evitar cualquier tipo de colisión (más de "buena fe" que legal), me apunto a pwsh .

Déjame preguntarlo de esta manera: ¿alguien tiene una razón de peso para pwsh ?

¿Alguien tendría preocupaciones si pwsh es el nombre del ejecutable y powershell es el enlace simbólico / acceso directo?

Antes de hacer alguna aprobación aquí, deberíamos responder qué es la versión "actual" y cómo nos referiremos a ella y su versión de destino.

@iSazonov no estoy seguro de entender tu pregunta. Esto no está relacionado con powershell -v N si eso es lo que está preguntando. Esto simplemente permite usar pwsh lugar de powershell (aunque todavía admitiríamos que se deletreara powershell ).

Mi preocupación es más sobre enlaces simbólicos como powershell -> powershell-6.0.0-beta.7
Si hablamos del lenguaje, nos gustan los alias en la sesión interactiva porque nos da un ambiente cómodo, pero los alias son un gran dolor de cabeza en los scripts. Veo lo mismo para el nombre corto de PowerShell: probablemente sea bueno para el tipo de velocidad, pero puede ser realmente un problema para el árbol de directorios (enlaces simbólicos).

Otro pensamiento. ¿Deberíamos pensar en el tipo de velocidad? No todos los casos propuestos son buenos desde esta perspectiva.
El último pensamiento es sobre pronunciación. Interesante, en ruso usamos "пош" ("elegante") e hipocorismo "пошик" ("poshik") desde el nacimiento de PowerShell. Supongo que cualquier ruso votará por "pijo" o "psh".

Para que quede claro, pwsh no sería un alias (en términos de PowerShell), debería ser algo que pueda llamar desde cmd.exe o un archivo por lotes tal como existe físicamente. Aunque no tengo claro cómo implementamos esto realmente si queremos admitir tanto un nombre corto como powershell sin tener dos ejecutables (aunque poweshell.exe es relativamente bastante pequeño ...).

En cuanto a posh y psh vs pwsh , la principal preocupación con posh y psh es que ya existen (independientemente de lo prominentes que sean son). Tuvimos un problema al principio con nuestro alias curl ya que entraba en conflicto con una herramienta nativa existente y (quizás somos demasiado cautelosos aquí) estamos tratando de evitar una situación similar con la mano corta, por lo que te estás inclinando hacia pwsh . Quizás si escribo pwsh con suficiente frecuencia, la gente se acostumbrará :)

Otro lado. ¿Cómo resolvemos lo mismo en PowerShell? Sugerimos que los usuarios utilicen alias e IntelliSense para empezar a escribir.
Cuando discutimos los alias en una de las discusiones aquí, dijimos que todos los alias actuales no deberían ser de solo lectura, deberíamos permitir que los usuarios eliminen / cambien cualquier alias. En otras palabras, los alias no deben ser exclusivamente estándar. Solo los nombres de cmdlet básicos deben ser estándar. Desde este punto de vista, no deberíamos ofrecer un alias "estándar" para "powershell" - cualquier comunidad o distributiva debería poder elegir el nombre que le guste y que corresponda a su espíritu, también podría ofrecer IntelliSense.

@ SteveL-MSFT - Creo que 'pwsh' probablemente se quedará bien con la gente.

Dicho esto, ustedes mencionaron el incidente de curl como una razón para no usar 'psh'. ¡Encuentro eso problemático ya que simplemente te estás acorralando (a nosotros) en una esquina al dibujar paralelos demasiado lejos!

'curl' es una de las herramientas más utilizadas en el mundo linux. Es aconsejable ser demasiado cauteloso para no repetir el error "curl" para el software abandonware ?

Dejemos que el incidente del rizo nos enseñe una lección, pero no la incorrecta.

En apoyo del consejo de análisis directo de

Yo votaría por psh: el proyecto que citas como una colisión no ha tenido un lanzamiento en 10 años y nunca estuvo en repositorios de paquetes en ningún caso.

En otras palabras: el hecho de que psh aparentemente nunca fue parte de los repositorios de paquetes (principales) (solo he verificado apt (Ubuntu, Debian) y yum (Fedora, RedHat)) - es decir, siempre fue un _producto original_ - _y_ que, a todos los efectos, se puede considerar abandonado después de más de 10 años de inactividad, lo que lo convierte en un candidato perfecto.

(Por el contrario, el hecho de que posh siga siendo un paquete disponible a través de apt , independientemente de su estado de mantenimiento, lo descalifica, en mi opinión).

Estoy de acuerdo con los puntos señalados en que psh es una opción viable y debe considerarse

En cuanto a cómo _implementar_ el nombre corto como enlace simbólico / código auxiliar, asumiendo que el nombre del ejecutable real seguirá siendo powershell[.exe] :

Supongamos que el nombre corto será, digamos, psh (solo para elegir uno de los nombres discutidos, al azar).

Plataformas Unix

El instalador _addicionalmente_ tendrá que hacer el equivalente a lo siguiente:

# Linux
/usr/bin$ sudo ln -s powershell psh

# macOS
/usr/local/bin$ sudo ln -s powershell psh

En otras palabras: cree un enlace simbólico adicional llamado psh que simplemente apunte al enlace simbólico powershell .

En macOS, esto daría como resultado una cadena de enlaces simbólicos como la siguiente:

/usr/local/bin/psh@ -> /usr/local/bin/powershell@ -> /usr/local/microsoft/powershell/6.0.0-beta.7/powershell

Cualquier shell de llamada, incluido el propio PS Core, podría usar psh como una alternativa más corta a powershell .

Ventanas

En Windows, las cosas son más complicadas:

• al menos a partir de beta.7, desde _fuera_ de PS _Core_, solo _Windows_ PowerShell está en la RUTA.
• Debe haber abreviaturas distintas para Windows PowerShell frente a Powershell Core para la invocación dirigida: psh para PS Core y wpsh para Windows PS (este nombre también debería estar bien, porque tampoco está en uso en los apt y yum ).

PS de Windows

_Windows_ PS podría definir enlaces simbólicos, uno en cada $env:SystemRoot\System32\PowerShell\v1.0 (64 bits) y $env:SystemRoot\SysWOW64\PowerShell\v1.0 (32 bits) de la siguiente manera:

Set-Location $PSHOME
cmd /c mklink wpsh.exe powershell.exe

En virtud de que $PSHOME está en $PATH , cualquier shell, incluido PS Core y Windows PS, podría invocar Window PS como wpsh .

PS Core

El archivo de taquigrafía por sí mismo podría colocarse en un directorio que está en la RUTA de forma predeterminada, lo que permitiría la invocación incluso sin que $PSHOME PS Core esté en la RUTA.

No se aplican consideraciones de 64 bits frente a 32 bits (PS Core solo es de 64 bits), por lo que se podría elegir $env:SystemRoot (normalmente, C:\Windows ).

Desafortunadamente, el uso de _ enlaces simbólicos_ es al menos actualmente _no_ una opción, porque PowerShell Core se niega a ejecutarse cuando se invoca a través de un enlace simbólico que tiene un nombre diferente:

Desde una sesión de PS _elevada_:

Set-Location $env:SystemRoot   # typically, C:\Windows
cmd /c mklink psh.exe "C:\Program Files\PowerShell\6.0.0-beta.7\powershell.exe"

La invocación de psh.exe falla de la siguiente manera:

The managed DLL bound to this executable: 'powershell.dll', did not match own name 'psh.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

Si alguien conoce alguna forma de evitar esto, háganoslo saber.

(Curiosamente, si define el enlace simbólico _sin extensión_ - psh lugar de psh.exe - la invocación se realiza correctamente en principio, pero no se pasan parámetros).

Una solución alternativa es utilizar un archivo por lotes de código auxiliar (de nuevo, ejecutar desde una sesión de PowerShell _elevated_):

Set-Location $env:SystemRoot   # typically, C:\Windows
'@"%ProgramW6432%\PowerShell\6.0.0-beta.7\powershell.exe" %*' | Set-Content -Encoding ASCII psh.cmd

Cualquier shell de llamada, incluido Windows PowerShell y el propio PS Core, puede usar psh como abreviatura para invocar PS Core.

@ mklement0 Estaba pensando lo mismo en términos de usar un enlace simbólico en Linux / macOS y un archivo por lotes para Windows (y no haría nada por Windows PowerShell, ya que quedaría como powershell ).

Parece que lo más obvio es que powershell es el principal y psh es el enlace, pero estaba pensando que tal vez deberíamos darle la vuelta para que psh sea ​​el nombre de el exe y powershell es el enlace. El razonamiento es que con una nueva audiencia que no es Windows y para diferenciarse de Windows PowerShell, parece que la preferencia es que la gente use psh para referirse a PowerShell Core y powershell solo se proporciona para app-compat (quizás memoria muscular para algunas personas durante la transición). Sin embargo, sé que no todo el mundo está convencido de esta idea.

Si vemos que psh muy popular, podemos intercambiar powershell y psh .

Para agregar alias puede ser de ayuda https://stackoverflow.com/questions/2016722/one-dll-multiple-projects

No me gusta la idea de que psh se convierta en exe y que PowerShell quede relegado a ser un enlace. Está desperdiciando 10 años de lealtad de la audiencia por una posible facilidad de uso en aplicaciones que no son de Windows, donde el tamaño de la audiencia es desconocido y (al menos para empezar) potencialmente pequeño.

Cuanto más veo de PowerShell v6, más parece que se ignora a los usuarios de Windows existentes en un intento de convencer a los usuarios que no son de Windows para que adopten PowerShell. ¿Dónde termina este proceso?

@RichardSiddaway No tengo la impresión de que el equipo de PowerShell esté ignorando a los usuarios de Windows y yo soy principalmente un usuario de Windows con un Windows Phone. Yo fui quien solicitó esto, no por algún concepto de Linux, sino por mis propios desafíos de pasar de cmd a powershell.

El hecho es que Windows PowerShell es un producto maduro, pero no se ha creado pensando en la multiplataforma. Para que esto funcione, la inversión inicial tiene que ser mayor hacia la multiplataforma al principio, lo que beneficiará a ambos mundos. Las cosas se equilibrarán en los próximos lanzamientos.

Aparte de los alias y los alias de parámetros, no veo mucho que afecte negativamente a los usuarios de Windows. Si hay un problema específico que le preocupe, por favor planteelo en esos problemas. El debate es bueno para la plataforma y debemos asegurarnos de que nada especial sobre PowerShell se pierda en la transición.

@ SteveL-MSFT, ¿puede proporcionar más de su razonamiento para hacer que psh o pwsh convierta en el .exe? Si se obtienen beneficios de ello, es posible que me sienta más inclinado a favorecerlo.

Ay en el archivo por lotes. De todos modos, ¿hacer que el enlace simbólico funcione en Windows? Prefiero tener eso que otra capa a través de cmd.

@ dragonwolf83 Me imagino que con el tiempo, la gente preferiría escribir 3 o 4 caracteres en lugar de 10, por lo que, aunque siempre apoyaremos la escritura powershell , parece que, desde una perspectiva a largo plazo, deberíamos optimizar para la versión más corta

Sus comentarios sobre Windows PowerShell son acertados.

@ dragonwolf83 :

Ay en el archivo por lotes. ¿Alguna forma de hacer que el enlace simbólico funcione en Windows?

Te escucho. Por desgracia, mi grito de ayuda ha recibido muy poca atención hasta ahora.

powershell.exe es 78k, sería tan malo tener otros 78k como psh.exe ...

Tener 2 ejecutables duplicados podría ser una solución fácil, pero también podría generar confusión, ya que puedo imaginar que los usuarios comenzarán a reflexionar sobre si hay una diferencia entre los 2. Si fuera nuevo en PowerShell y viera 2 ejemplos diferentes (por ejemplo, en SO) que mostrar cómo llamar / abrir PowerShell, entonces inmediatamente comenzaría a preguntarme qué ejemplo debería elegir porque asumiría que hay una diferencia ...

En mi opinión, esto es una tontería. cmd.exe está en gran parte oculto en Windows 10 1703, por lo que rara vez lanzaría powershell.exe desde el shell heredado.

No soy un gran admirador de esto, ¿con qué frecuencia escribe powershell que se convierte en un problema? (Además, problema total de bikeshed;)) En Windows 10 y Server 2016, configure "Reemplazar el símbolo del sistema con Windows PowerShell cuando hago clic con el botón derecho en el menú de inicio o presiono Win + X" y es tan corto como Win + x, io en Linux , agregue un alias a su shell existente con el nombre que prefiera.

Dicho esto, ¿qué pasa con:

• ps1 - después de la extensión del archivo en Windows, breve, fácil de escribir, memorable
• psps - es corto y se puede escribir, pero se deja abierto a los comentarios 'típicos de M $ hinchazón'
• ips - como si fuera para Invoke-PowerShell, no parece ser un paquete en los repositorios de RedHat o Ubuntu y yum provides "*/ips" no muestra binarios con los que chocar en una verificación rápida

Déjame preguntarlo de esta manera: ¿alguien tiene una razón sólida para no optar por pwsh?

Es feo e impronunciable, requiere más sílabas para decir que 'powershell' en sí, no es particularmente fácil de escribir y parece que se deriva de pwnd / pwnt, que se habla en Internet.

Si pronto tendremos PowerShell como shell predeterminado en Windows, el nombre del archivo (longitud) deja de ser importante.

PowerShell Core es un proyecto portátil; también tenemos que pensar en Unix.

@ PowerShell / powershell-Committee discutió esto y donde aterrizamos es para tener el binario PSCore6 llamado solo pwsh sin un atajo / alias adicional para powershell . El beneficio es hacerlo explícito sin ambigüedad en Windows, ya sea que esté usando Windows PowerShell o PowerShell Core. En los que no son Windows, es más corto de escribir y más consistente con otros nombres de shell. Según los comentarios de los clientes, siempre podemos agregar un enlace / acceso directo / alias powershell en el futuro.

Mi voto es psh.exe.

@jandrusk El PR ya se fusionó ayer, por lo que será pwsh.exe. Jeffrey ya ha tuiteado sobre esto aquí .

¡Viva la nueva PassWord / Per-Week / PoliceWoman SHell!

Mi voto hubiera sido dejarlo en paz.

Entonces, ¿cómo pronunciamos pwsh?

pwsh
p.wush
p.woosh
puh.wush

Ojalá algo mejor que esos

@jonathanmedd He estado usando pwish como wish con un p .

Dado que _pwsh_ es un acrónimo recursivo (similar a _GNU_) - Por favor, ¿por qué pwSH? - Sugiero "pweesh", como un lindo conejito con un ceceo que dice "por favor".

Bromas aparte:

• Aunque personalmente creo que decidirse por pwsh fue desafortunado, supongo que nos acostumbraremos pronto y no lo volveremos a pensar.

• En cuanto a la pronunciación: personalmente no veo la necesidad de uno, dado que el nombre completo es lo suficientemente corto, y para cualquiera que viva en el mundo de PowerShell, el mapeo será obvio. (Un ejemplo del mundo Unix: zsh aparentemente se pronuncia zee shell o zed shell , no como una sola sílaba).

P-Dub Shell ?

P Double U Shell o P Double U S H es simplemente doloroso de decir. Más sílabas que PowerShell pero probablemente quieras distinguir PowerShell de pwsh . Así como bash se distingue de Bourne-Again Shell .

probablemente querrá distinguir PowerShell de pwsh

En términos de los nombres completos oficiales, es _PowerShell Core_ vs _Windows PowerShell_ - _PowerShell_ por sí mismo puede referirse a cualquier edición.
Si no está claro por el contexto, agregar el calificador apropiado eliminará la ambigüedad, y tal vez no sea necesario con tanta frecuencia (por ejemplo, en un contexto Unix puro).

A más largo plazo, dado que PowerShell Core es la edición que se ejecuta en "todas" las plataformas, no me sorprendería que _PowerShell_ se convirtiera en una abreviatura común e informal de _PowerShell Core_ (el PowerShell "predeterminado"), con un calificador - _Windows_ - solo se usa para referirse a la edición de Windows.

Como un aparte:

Al igual que bash se distingue de Bourne-Again Shell.

bash _es_ el _Bourne-Again SHell_ - contrasta con su predecesor, el _Bourne SHell_ ( sh ,
antes de que POSIX estandarizara el lenguaje).

@ mklement0 Estoy hablando de distinguir pwsh el binario de PowerShell el lenguaje / shell. No distinguir diferentes implementaciones / plataformas de PowerShell. Así como se usa bash para distinguir el binario de Bourn-Again SHell . Son intercambiables, sí, pero cuando necesitas distinguir los 2 necesitas una forma clara de pronunciar pwsh .

empujar: sonrisa:

Así que tal vez:

p shell o p w shell

@markekraus :

Ah, ya veo, gracias por aclararme.

Si desea transmitir el nombre _exacto_ del binario, ninguna pronunciación excepto _deletrear_ el nombre lo ayudará (eso solo habría funcionado con algo como posh ).

Por lo tanto, referirse al binario / ejecutable de _PowerShell_ debería funcionar para todos aquellos que ya lo conocen, y para otros tendrá que deletrearlo de todos modos.

Si desea transmitir el nombre exacto del binario, ninguna pronunciación, salvo deletrear el nombre, le ayudará.

Tendremos que aceptar estar en desacuerdo con eso 😃.

Entiendo su _ deseo_ de que eso funcione, como lo hace con "bash" y "posh", por ejemplo, pero como lo atestiguan sus propias luchas anteriores, no funciona con "pwsh", lo cual, es justo asumir, nosotros Estás atrapado ahora.

no funciona con "pwsh"

bueno, no con esa actitud! 😉 Lo he estado llamando pwish y probablemente continuaré haciéndolo. Pero solo estoy creando un diálogo para ver si a otros se les ocurre algo más. push es bueno considerando la pronunciación w en algunos idiomas. pwsh no completamente irredimible, IMO. tal vez todos se conformarán con p w s h . pero es demasiado pronto para decir "hemos terminado aquí" y considerar el asunto decidido, en mi opinión.

:)

Tienes razón.

Supongo que me estaba enfocando demasiado en el aspecto de transmitir la _ ortografía exacta_ a alguien que aún no está familiarizado con PowerShell en lugar de un nombre corto establecido _por convención_ para aquellos que ya lo saben (que ya saben cómo asignar ese nombre corto a pwsh ).

¿Qué pasa con MSPosh. ¿Más corto que PowerShell.exe y sigue los estándares, al mismo tiempo que se duplica como un nombre divertido para The PowerShell Hero ?

@ 1RedOne, el héroe / avatar de PowerShell siempre será PoSH-Chan en mi ❤️

Parece que el equipo de PWSH se apresuró a cambiar su nombre. :-)

Yo voto por pscmd.exe

al escribir cmd en Windows, ¡debería aparecer! y en realidad está reemplazando el cmd ...

si esto es una cuestión de memoria muscular, solucionemos ese problema.

si es sólo por diversión encontrarle un nombre nuevo y atractivo, entonces debería ser pscore.exe, ya que eso es lo que es.

solo mis 2 centavos.

pwsh , el shell fwremwst Wbject-Wriented del wwrld. Estoy mirando hacia adelante dos nuevos cmdlets que continúan con este patrón:

Get-Cwntent servers.txt | FwrEach-Wbject { 
    Invwke-Cwmmand -CwmputerName $_ -Scriptblwck { .. }
}

;)

-

Pronunciación de ref, ¿qué pasa con " powsh ", dijo como "bolsa" o "sofá" con una "s" suave. (Piense en los impresionistas de Sean Connery diciendo "bolsa").

The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

Supongo que este mensaje de error está relacionado con este problema. ¿Cómo puedo solucionar esto?

En cuanto a la cuestión del nombre real, voto por pwsh, ya que Bash es el Bourne Again SHell.

Voto por PWSH. Y lo pronunciaría como empujar.
Sin embargo, he visto muchos en la comunidad que usan elegante, por lo que esa sería mi segunda opción, aunque creo que MS puede estar tratando de evitar llamarlo elegante.

¡Voto por pwr !

@DaleMitchell, ¿cómo

Aunque he visto muchos en la comunidad usando elegante

https://github.com/dahlbyk/posh-git por ejemplo.

pwsh se pronuncia posh . @SaschaNaz POSH ya existe como un shell desafortunadamente

¿Me perdí una votación de @ PowerShell / powershell-Committee sobre cómo se pronuncia? :)

Pensé que tal vez podríamos pronunciarlo Microsoft Next Generation Command Line Interface Shell Experience 2017 , o tal vez solo, ya sabes, powershell .

No lo usará hasta que se lance el Service Pack 2 de Microsoft Next Generation Command Line Interface Shell Experience 2017 ...

POSH ya existe como un caparazón desafortunadamente

Sí, será MUY confuso cuando un usuario quiere pijo, prueba sudo apt install posh y luego obtiene un shell completamente diferente.

Por cierto, ¿ poh-sh o pah-sh ? ¿Seguramente lo último?

El nombre del paquete sigue siendo powershell, no hay cambios allí:

sudo apt install powershell

Una publicación rápida (obstinada) sobre el estado del debate:

• En cuanto al _nombre de archivo del binario_: la decisión se ha tomado y se ha publicado: pwsh es.

• En cuanto a _pronunciación_:

  • No hay nadie que pueda transmitir la ortografía exacta del binario al _in iniciado_, no hay más remedio que deletrearlo.

  • Para el _iniciado_, "PowerShell" es posiblemente todo lo que se necesita, ya que por lo general quedará claro por el contexto si uno se está refiriendo al _producto_ o al _nombre de archivo del binario_ (preocupación de @markekraus ); si es el último, el iniciado lo traducirá automáticamente a pwsh en sus cabezas.
    Agregue "Core" y "Windows" para eliminar la ambigüedad, si es necesario.

  • No hace falta decir que la búsqueda apasionada del apodo informal definitivo de una sílaba continuará ...
    Dado que en cualquier caso se requiere un acto de mapeo mental en pwsh , los establecidos de manera informal como "Posh" también pueden seguir utilizándose.

En los viejos tiempos, cuando usábamos MKS Toolkit para soporte de scripts multiplataforma, usábamos ksh.exe pero siempre lo llamábamos KornShell . Entonces, aunque el binario es pwsh , lo llamaré PowerShell.

Creo que todo este problema de "cómo se pronuncia el nombre binario" podría haberse evitado si el nombre binario hubiera sido pwrsh pero ese barco ya zarpó.

En los "viejos tiempos" (¿cuenta hace 15 años?) Mi equipo llamaba al binario "kish", y "KornShell" era para la discusión general del shell.

Ejemplo:

"Escribe ooser bin kish y luego presiona Enter. Ahora estás en KornShell"

hace 15 años cuenta?

Supongo que es algo relativo a la persona. Mi experiencia con KornShell comenzó hace 24 años. Hace 15 años mi hija era una niña pequeña y eso no parece que fuera hace tanto tiempo. Ay, el tiempo vuela.

mi equipo llamó al binario "kish"

No puedo decir que alguna vez lo haya escuchado pronunciar de esa manera. :-)

No puedo decir que alguna vez lo haya escuchado pronunciar de esa manera. :-)

Sí. fuera de ese equipo siempre ha sido "ksh" o "KornShell". Pero ese es el punto: discutir cómo la gente pronunciará las letras "pwsh" (en ausencia de "PowerShell") y ver si hay algún consenso. No es una discusión completamente seria y nada va a ser una pronunciación oficial ya que es una palabra impronunciable (sin faltarle el respeto al equipo- push ). pero tiene el mérito de que tal vez un competidor popular gane y empecemos a escucharlo en las presentaciones.

Antes de trabajar en Microsoft, era una persona de Unix y siempre había llamado ksh Korn Shell y csh C Shell. No recuerdo a nadie en esos días tratando de pronunciarlos como palabras: P

¿Alguien podría explicar de manera concisa por qué se realizó un cambio radical como este? Estoy fuera del circuito (¡claramente!), Y estaba charlando con @powerschill , y estamos algo sorprendidos, dado que los enlaces simbólicos son una cosa.

Hice mi lectura de actualización sobre el proceso de contribución hace un momento. Pensé que esto requeriría un RFC al principio, pero puedo ver cómo esto puede no aplicarse. A continuación, analizo la política sobre cambios importantes (https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md). ¿Pueden comentar en qué cubo cayó este cambio, y así sucesivamente?

Sin tratar de provocar algo que está claramente resuelto, solo quiero poder comunicarme de manera efectiva con otros interesados ​​que no vayan a leer especificaciones y problemas. ¡Gracias!

@ halr9000 https://github.com/PowerShell/PowerShell/issues/4214#issuecomment -335989245

mi 2c. Este es un gran cambio radical. Demasiados archivos por lotes existentes en escenarios de producción existentes ya usan powershell.exe para iniciar scripts de PowerShell. No estoy en contra de proporcionar un comando corto adicional para iniciar el mismo ejecutable, pero eliminar 'powershell' causará grandes estragos. Proporcione una forma de usar ambos (alias o lo que sea)

@RudolfHenning A diferencia de las versiones anteriores de Windows PowerShell, PowerShell Core funcionará en paralelo con otra versión de sí mismo y con versiones anteriores de Windows PowerShell. Debe haber una forma de llamar tanto a Windows PowerShell como al núcleo de PowerShell desde la línea de comandos y desde scripts por lotes sin tener que llamar a la ruta completa del EXE deseado o sin arriesgar el orden de la ruta, lo que da como resultado que powershell.exe llame al incorrecto versión.

Incluso después del lanzamiento de PowerShell Core 6.0, seguirá siendo necesario utilizar Windows PowerShell (5.1 y versiones anteriores) para muchas tareas centradas en Windows, ya que muchos de los módulos y scripts oficiales y comunitarios requieren acceso a objetos de CLR completo que no están disponibles en Core.

Además, cualquiera que transfiera sus scripts de versiones anteriores a 6.0 probablemente necesitará hacer ajustes, ya que hay bastantes cambios importantes entre 5.1 y 6.0. Dado que el código deberá tocarse de todos modos, el lote se puede cambiar a pwsh.exe desde powershell.exe . Si no están portando PowerShell Core, nada se romperá y los scripts continuarán ejecutándose con powershell.exe usando Windows PowerShell.

Gracias por la explicación.
Dado que estoy usando Windows y algunos sistemas operativos Linux, la compatibilidad de mis scripts es una preocupación a veces; sí, sé que las bibliotecas de PowerShell en Linux son estrictamente Beta. He invertido bastante tiempo y esfuerzo en la creación de scripts para mis máquinas Linux.
De todos modos, ¡sigue haciendo el buen trabajo!

El corredor Powershell de TeamCity asume que el ejecutable se llama powershell . Dado que no hay Powershell 5 en Linux que cause problemas de compatibilidad, el paquete de Linux debería haber seguido creando el enlace simbólico powershell . Esta fue una rotura innecesaria.

¿Qué diablos, llegué en abril? ¿Vamos a eliminar las vocales de los comandos de PowerShell a continuación? Esto debe ser una broma.

Los scripts más antiguos (docker) que usan "powershell -command xxxx" ya no funcionan con la nueva versión beta-9 ...

esperando la tormenta de mierda

Puede haber muchas razones para realizar un cambio radical en el lugar o punto de entrada "más importante", pero acortar el nombre del comando en 6 bytes y hacerlo menos legible no es una de ellas ...
con qué frecuencia en el pasado decidimos usar un nombre mejor / más largo dentro de nuestro código porque leer puede / debe ser más fácil que escribir ...

cust mi 2cent
Saludos
Werner

Estoy tratando de entender la indignación y el fracaso.

La gente se queja de que el nuevo nombre está rompiendo cosas, pero PowerShell Core todavía está en versión beta. En mi opinión, si alguien está usando una tecnología beta en el código de producción, está invitando al desastre (estoy usando un lenguaje educado aquí). La naturaleza de las versiones alfa y beta es la de estar llena de cambios importantes. No hay ilusión de que esto no sea beta. beta se incluye en el nombre de la versión: 6.0.0-beta.9 .

Este cambio de nombre no tiene ningún efecto en Windows PowerShell. No debería romper nada de lo que está haciendo actualmente en Windows. Si está haciendo cosas en Linux, entonces debe reconocer el hecho de que está usando una versión beta, en lugar de culpar a la versión beta por ser una versión beta. Considere usar algo más hasta que la versión estable sea RTM si no puede manejar los cambios importantes entre las versiones beta.

Entiendo que a la gente no le gusta el nombre. No siempre puedes conseguir lo que quieres. Personalmente, he odiado PowerShell.exe porque es largo e incómodo de escribir. pwsh son al menos menos caracteres para que pueda estropearlos. Si observa el hilo de discusión, puede ver que se discutieron múltiples opciones, algunas de ellas mucho peores (IMO) que pwsh .

La gente malinterpreta esto como un intento incómodo de mezclarse con los chicos geniales de Linux, cuando uno de los principales motivadores para un nuevo nombre binario está relacionado con Windows. Sí, se eligió un nombre linux-y, pero ¿adivinen qué? PowerShell ahora también es un ciudadano * nix. Creo que es hora de que la gente se acostumbre a ese hecho. Uno de los objetivos de Core es la portabilidad multiplataforma, así que sí, las decisiones pueden y se tomarán teniendo en cuenta más que Windows.

así que ese es mi valor de 2 centavos.

Uno de los objetivos de Core es la portabilidad multiplataforma

Una parte de la portabilidad multiplataforma es que los mismos comandos deberían funcionar en ambas plataformas si hacen lo mismo. Antes de este cambio, podía ejecutar powershell sin importar qué sistema operativo estaba usando y obtener lo correcto. Ahora ya no puedo hacer eso.

Hacer software que sea fácil de usar significa cuidar adecuadamente un millón de pequeñas cosas. Usar nombres extraños y poco intuitivos funciona en contra de eso.

Podría ejecutar powershell sin importar qué sistema operativo estuviera usando y obtener lo correcto. Ahora ya no puedo hacer eso.

No es correcto. Puede ejecutar powershell en Windows y obtener Windows PowerShell, luego ejecutar powersehll en Linux y obtener PowerShell Core. Ahora puede ejecutar pwsh en Windows o Linux y obtener PowerShell Core. Así que AHORA estamos en el estado que deseas. donde como antes estábamos en un estado inconsistente.

Usar nombres extraños y poco intuitivos funciona en contra de eso.

bueno, está claro que no es del agrado universal, pero ... ¿qué alternativa sugieres? Veo que todos se quejan del nombre, pero no hay alternativas al problema subyacente: este cambio de nombre se dirige. Como dije: "No siempre puedes conseguir lo que quieres"

Independientemente del nombre elegido, la gente no estaría contenta.

@markekraus

• sabemos que es una versión beta - ¡los cambios importantes están bien!
• Soy un gran fanático de mejorar PS en * nix porque me ayuda a transferir mi conocimiento (PS) de Windows a * nix

Mi retroalimentación fue sobre la usabilidad y la preocupación de una tormenta de mierda que obliga a algunos cambios de nombre nuevamente y discusiones interminables.

Puede ejecutar PowerShell en Windows y obtener Windows PowerShell, luego ejecutar PowerShell en Linux y obtener PowerShell Core. Ahora puede ejecutar pwsh en Windows o Linux y obtener PowerShell Core. Así que AHORA estamos en el estado que deseas. donde como antes estábamos en un estado inconsistente.

¡Separar Windows y Core es realmente una MEJOR razón para el cambio de nombre y luego "Crear un nombre más corto"!

Sugiero hacer comunicaciones más claras al respecto (título del problema, notas de la versión, etc.)
He leído las primeras 2-3 páginas de este número y la discusión fue solo sobre la extensión ...

otros comentarios:
En las últimas semanas he realizado muchas codificaciones con PS-Core en Docker y * nix
Me gusta pero necesita un poco de pulido.
Idea / sugerencia:
si el nombre se cambia de Powershell a pwsh, ¿por qué no cambiar la versión de 6.0 a 1.0 (la misma discusión como la transformación de ".Net 5.0" a "dotnet core 1.0
Básicamente, CORE se parece más a una versión 1.0 que a una versión 6, especialmente en * nix !!

Saludos
Werner

@WernerMairl Hay una discusión abierta sobre el uso de 1.0 en lugar de 6.0.0 # 5165. Vaya a ese hilo y lea y comente.

Además, dado que lo ha estado usando y se ha encontrado con cosas que cree que necesitan pulirse, verifique los problemas abiertos para ver si abordan lo que ha encontrado. Si hay un problema abierto, vote sobre él o comente y, si no es así, abra un nuevo problema para que se pueda solucionar. Varios de nosotros, miembros de la comunidad, participamos activamente en la solución de los problemas de menor prioridad y el equipo de Microsoft ha estado haciendo un trabajo increíble al resolver los problemas de mayor prioridad y más difíciles. Además, ¡nunca es demasiado tarde para convertirse en colaborador!

En cuanto a la descripción del problema y la comunicación del cambio, estoy de acuerdo en que había margen de mejora en la comunicación de este cambio y por qué era necesario. Los roles de diferentes personas en este repositorio pueden ser un poco confusos, pero no soy parte del equipo de PowerShell, solo un colaborador de la comunidad con privilegios de moderación de foros (esencialmente). No puedo hablar por el equipo de PowerShell, pero sospecho que ellos mismos entienden este hecho.

En su defensa, este es un poco difícil de comunicar. La mayoría de las quejas parecen provenir de la falta de comprensión de las similitudes y diferencias entre Windows PowerShell y PowerShell Core. Para comunicar eficazmente este cambio, también habrían tenido que repetir lo que se explicó en el artículo del blog del 14 de julio . Lo cual, incluso entonces, la gente todavía tiene dificultades para navegar por las similitudes y diferencias. Creo que necesitaría una descripción extensa de por qué se hizo el cambio de nombre que muchos todavía no leerían. Sospecho que las antorchas y las horquillas habrían llegado sin importar nada.

No es correcto. Puede ejecutar PowerShell en Windows y obtener Windows PowerShell, luego ejecutar PowerShell en Linux y obtener PowerShell Core. Ahora puede ejecutar pwsh en Windows o Linux y obtener PowerShell Core. Así que AHORA estamos en el estado que deseas. donde como antes estábamos en un estado inconsistente.

Entiendo lo que quiere decir, pero respondo que esto no es lo que quiero. Hay una suposición oculta implícita en mi declaración: espero que PowerShell y PowerShell Core sean completamente equivalentes siempre que use características comunes. Hasta ahora, esto no ha tenido problemas en todos mis casos de uso.

@sandersaares Creo que tu experiencia ha sido de suerte. Ciertamente no coincide con mi experiencia. Además, creo que esa suposición es peligrosa. Esta es una versión principal con un montón de cambios rotundos documentados con una plataforma subyacente completamente diferente. Esto no será como las versiones principales anteriores de PowerShell con casi un 100% de compatibilidad con versiones anteriores.

Veo que algunas personas todavía hacen la falsa suposición de que el cambio del nombre del ejecutable fue principalmente para ahorrar al escribir. Puedo ver cómo la gente pudo haber tenido esta impresión desde que este número original que se usó para las relaciones públicas comenzó con un título que pedía un nombre más corto.

Estoy de acuerdo en que podemos mejorar nuestra comunicación, ya que no deberíamos esperar que todos lean todos los comentarios que hace el Comité sobre las decisiones. Particularmente en uno controvertido como este, donde el resumen de la decisión se pierde fácilmente.

También parece que existe un malentendido fundamental de lo que es PowerShell Core 6, particularmente en relación con Windows PowerShell. Windows PowerShell 5.1 sigue siendo y será la versión incorporada de PowerShell en Windows. Mi equipo también continúa apoyándolo según sea necesario. Esperamos que los clientes sigan confiando en Windows PowerShell durante el tiempo que lo necesiten, lo que podría ser al menos durante los próximos 10 años. Creo que fue solo recientemente cuando las descargas de WMF5.1 finalmente superaron las descargas de WMF4.0.

PowerShell Core 6 es la próxima evolución de PowerShell, donde no solo es multiplataforma, sino también de código abierto. Como señaló @markekraus , es un cambio de versión importante que nos permitió más flexibilidad para aceptar cambios importantes que nunca consideraríamos para Windows PowerShell. También señaló que PowerShell Core 6 está diseñado explícitamente para funcionar en paralelo (no solo con Windows PowerShell sino con otras versiones de PSCore6). No debe haber ambigüedad de lo que obtiene en Windows cuando escribe powershell . Solo señalaré aquí que la discusión de 6.0 vs 1.0 ya ocurrió hace mucho tiempo antes de que saliéramos a bolsa y es poco probable que se vuelva a abrir.

@ SteveL-MSFT una publicación de blog sobre el cambio de nombre sería bueno. Podría cubrir el controlador principal de por qué el nombre cambia con un ejemplo claro del problema en Windows. También sería bueno explicar por qué posh y psh no hicieron el corte también.

Tal vez configure "powershell" como un alias para pwsh durante el desempaquetado + instalación. Esto acaba de romper una compilación en la que estuve trabajando durante un par de días hasta que encontré este problema.

Editar: en linux

@markekraus tiene una buena publicación de blog que captura el qué y el por qué:

https://get-powershellblog.blogspot.sg/2017/10/why-pwsh-was-chosen-for-powershell-core.html

Hoy vi el primer uso de pwsh en SO aquí, aunque dudo que la persona sepa sobre este hilo ...

¿Podemos obtener una decisión oficial sobre la pronunciación de pwsh ? La especificación PNG incluye una pronunciación en su Sección 1. También puede proporcionar una para PowerShell; no quiero otra situación SCSI "scuzzy" / "sexy".

A mí me parece un "poosh".

@apjanke la pronunciación generalmente aceptada de pwsh es posh

Funciona para mi. ¡Gracias por la confirmación oficial!

En cuanto a pronunciaciones alternativas: ^[1]

• _Pish Posh! _

• _Poppyposh! _

• _The Shell anteriormente conocido como PowerShell_ (_TSFKAP_ en georgiano )

• _La concha que no se atreve a pronunciar su nombre (porque el nombre de su ejecutable es impronunciable) _ (preferido por los hablantes de

^{[1] [Parodia.}