Powershell: Créez pwsh comme nom plus court pour appeler powershell.exe

Je voudrais un alias court aussi, mais c'est la raison pour laquelle nous n'avons pas aller avec posh quand nous avons d' abord allés (nous en avons parlé longuement). Semble également être un package à jour.

Ouvert à d'autres suggestions, mais la plupart des plus évidentes * sh ont été prises. Après le seul alias wget / curl, j'aimerais vraiment éviter de heurter d'autres paquets, même s'ils sont moins courants.

Je ne suis pas trop fou de toute cette idée mais qu'en est-il de pwsh ?

Je n'ai jamais aimé le chic comme un raccourcissement de PowerShell. pwsh semble mieux mais une recherche rapide sur Internet soulève des problèmes possibles. si nous allons faire cela, je suggérerais aussi court que possible, alors qu'en est-il juste de ps?

OK - oubliez ça - je viens de réaliser que ps est un alias pour get-process. ce serait trop déroutant

Je reçois un fort déjà-vu en ce moment. 😉

J'apprécie la lisibilité de PowerShell (lorsque vous n'utilisez pas d'alias), donc exécuter powershell fonctionne bien pour moi.

ps est également une commande existante sous Linux.

Voici quelques autres idées: pscmd , psc , monad , psh , pshell

Il y a certainement des rendements décroissants avec ces noms, mais s'ils sauvent vraiment quelque chose ou ajoutent simplement une confusion inutile s'ils sont même disponibles.

CoreSh , pcs , psc

Dommage que mosh soit pris. psh est pris. [pshell] renvoie de nombreux résultats. Fait intéressant, une recherche de msh sur Bing et Google fait apparaître de nombreux résultats pour PowerShell (en l'appelant Microsoft Shell), bien qu'il existe un msh sous Unix (peut-être peu utilisé)

😄 S #, P #

@ PowerShell / PowerShell-Committee a discuté de cela et est ouvert à un nom de lien symbolique plus court, mais nous ne pouvons pas nous accroupir sur quiconque existe déjà. prsh semble correct.

Attendre attendre! Je l'ai eu: ^sh - ou était-ce **sh ? (jk).

prsh semble raisonnable - plus facile à taper que pwsh , par exemple, bien que pwrsh - bien qu'il s'agisse d'un caractère. plus long - vaut également la peine d'être considéré, étant donné que "pwr" est une abréviation connue pour "power".

Une autre option, éventuellement _complémentaire_: fournissez une _ variable automatique_ dont la valeur _invariablement_ reflète le même chemin du binaire qui a lancé la session en cours.

bash a $BASH pour cela.

L'avantage de cette approche est qu'elle est insensible aux variations / manipulations de $env:PATH .

Nous avons déjà $PSHOME - sans doute, quelque chose comme $PS n'est pas trop compliqué.

Cela dit, cela concerne la discussion sur la question de ne pas polluer l'espace de noms global avec des variables automatiques - voir # 4216.

.Net Core, CoreFX, CoreCLR, PowerShell Core - nous pourrions considérer "core" comme base.

pscore me semble bien même si cela ne se termine pas par sh bien que d'autres membres du Comité y aient opposé leur veto

pscore ou coreps - LGTM.

On se souvient de monad et msh (mentionné ci-dessus).

J'aime pwrsh le meilleur jusqu'ici. pscore n'est pas mal non plus même si cela devient assez long à 6 caractères. Quatre caractères ou moins sont probablement idéaux, mais je pourrais vivre avec les 5 caractères requis par pwrsh .

Ma préoccupation à propos de l'incorporation du mot "core" est qu'il ne contient aucune information utile sur les plates-formes Unix, où il n'y a pas d'autre édition dont il faut le distinguer.

@rkeithhill que diriez-vous de pscx , ha! Expérience PowerShell Core. Cependant, cela m'a fait penser à un autre, pscsh , PowerShell Core Shell.

Je suis déchiré par certains des mêmes noms moi-même. J'aime la lisibilité de pwrsh et pscore mais je suis d'accord que 5 caractères est la limite. 5 caractères couvrent le premier mot power et pas plus que cela, vous pouvez aussi bien taper le tout. monad est un excellent œuf de Pâques et lisible, mais déroutant pour ceux qui ne connaissent pas les antécédents de PowerShell. Le caractère 4 prsh fonctionne bien aussi.

Ce serait bien de proposer une liste finale de noms pouvant être utilisés et de faire un sondage officiel comme l'a fait l'équipe Edge. S'il y a des événements officiels ou de la communauté PS à venir, des liens vers le sondage peuvent être fournis pour essayer d'atteindre un public plus large.

@ dragonwolf83 :

pscsh est dangereusement proche de csh - une association à éviter.

Encore une fois, je ne vois aucun avantage à inclure le mot «core», surtout s'il y a une chance que les éditions soient unifiées un jour (et sur _Windows_, les gens semblent avoir vécu confortablement sans un nom court pour _Windows PowerShell_ pendant une bonne décennie) .

Accord sur l'obscurité de monad .

Mon vote personnel est pour pwsh , prsh ou pwrsh .

PS: Dans le cas où _Windows PowerShell_ aurait également besoin d'un nom court, le préfixe simple avec w pourrait être la solution, bien que parmi mes favoris, cela ne sorte que (raisonnablement) du clavier comme wprsh , donc dans le scénario du nom court en deux éditions mon vote est pour la paire prsh / wprsh .

Ma préoccupation à propos de l'incorporation du mot "core" est qu'il ne contient aucune information utile sur les plates-formes Unix, où il n'y a pas d'autre édition dont il faut le distinguer.

:-) Doit-on renommer .Net Core?

@iSazonov : Devrions-nous renommer Windows PowerShell "Windows PowerShell .NET Framework [FullCLR]?"

Je voterais pour psh - le projet que vous citez comme une collision n'a pas vu de sortie depuis 10 ans, et n'a en aucun cas été dans les dépôts de paquets.

@Jaykul :

psh ? Je ne sais pas - a besoin de plus de «noyau», si vous me demandez.

Blague à part: excellent point sur le statut du projet et son absence dans les dépôts de packages.

psh a aussi mon vote (et wpsh pour Windows PowerShell).

(Prononcé «pshaw» et «coup de fouet», respectivement).

psh a aussi mon vote (et wpsh pour Windows PowerShell).
(Prononcé «pshaw» et «coup de fouet», respectivement).

Êtes-vous sûr que nous ne pouvons pas simplement utiliser posh sur Windows et les prononcer pish posh? 🤡

Pish-tosh! C'est trop un méli-mélo pour tout le mishpocha. 🤡

Je voterais pour psh - le projet que vous citez comme une collision n'a pas été publié depuis 10 ans, et n'a en aucun cas été dans les dépôts de paquets.

Pas de problème de copywrite?

Aucun problème de droits d'auteur?

J'espère que quelqu'un qui sait vraiment pèsera, mais je suppose que ce ne sera pas un problème pour 2 raisons:

• psh n'est pas le nom officiel du produit, seulement un initialisme (acronyme plus vaguement) qui est simplement une aide technique (bien que dans un usage courant, cela puisse éventuellement devenir un raccourci courant pour le nom complet du produit; c'est possible aux sigles / acronymes de la marque).

• les problèmes de marques concernent souvent la probabilité d'une _confusion_ avec des marques existantes, et d'après ce que nous avons vu ici, au moins dans l'espace logiciel, il ne semble pas y avoir de collisions (je ne pense pas que le créateur du psh existant pratiquement disparu

Au cas où quelqu'un voudrait expérimenter / aurait besoin d'une solution provisoire:

Voici une solution tous les alias qui définit les alias à l'intérieur et à l'extérieur de PowerShell, sur toutes les plates-formes prises en charge: psh pour PS Core et wpsh pour Windows PowerShell.

• Exécutez UNE FOIS la suivante pour configurer des alias EN DEHORS de PowerShell (pour cmd.exe sous Windows, pour bash sous 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"
  }
}

• Mettez ce qui suit dans votre $PROFILE pour définir les mêmes alias à l'intérieur de PowerShell - fonctionne à la fois dans PS Core et 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"
  }

Et pour Paua ? Ceci est une référence à la belle coquille de paua (un coquillage de Nouvelle-Zélande). Sinon, je pense que psh est aussi bien.

Vous vendez des coquillages de la côte (néo-zélandaise)? (Je plaisante. Magnifique en effet.)

Avertissement: ce qui suit n'est d'intérêt que pour les linguistes [amateurs].

Phonétiquement, paua ne fonctionne que pour les dialectes non rhotiques de l'anglais (par exemple, Royaume-Uni, NZ, Australie).

Et les Bostoniens.

@ PowerShell / PowerShell-Committee devrait terminer sur ce point pour la version bêta.8

Que diriez-vous de Posh6

Que diriez-vous de Posh6

On dirait que cela deviendrait obsolète plus rapidement que de mettre un numéro de version dans une extension de fichier ...;)

Oui, mais un script shell qui le lance saura quelle version il exécute.

Bien que j'aime posh , je pense que la principale préoccupation est qu'il existe un package pour Linux appelé Posh, donc pour éviter un autre incident curl , je pense que la meilleure option suivante est pwsh

J'aime pwsh . Cela aurait été bien d'avoir 10 ans. Je manque msh .

Je vote pour psh .
gnp / psh n'a pas été engagé depuis près de 5 ans. Cela peut aussi bien être abandonware.

Je déteste le dire, mais c'est une de ces choses où il pourrait être trop difficile de parvenir à un consensus fort. : \

À ce stade, pour fermer les choses et éviter toute sorte de collision (plus de «bonne foi» que légale), je suis tout à fait d' pwsh sur

Permettez-moi de vous poser la question suivante: est-ce que quelqu'un a une bonne raison de ne pas choisir pwsh ?

Quelqu'un aurait-il des inquiétudes si pwsh est le nom de l'exécutable et powershell est le lien symbolique / raccourci?

Avant de faire des approbations ici, nous devrions répondre à ce qu'est la version "actuelle" et comment nous allons nous y référer et sa version cible?

@iSazonov pas sûr de comprendre votre question. Ce n'est pas lié à powershell -v N si c'est ce que vous demandez. Cela permet simplement d'utiliser pwsh au lieu de powershell (bien que nous soutenions toujours l'épellation powershell ).

Ma préoccupation concerne davantage les liens symboliques comme powershell -> powershell-6.0.0-beta.7
Si vous parlez de langage, nous aimons les alias en session interactive car cela nous donne un environnement confortable, mais les alias sont un gros casse-tête dans les scripts. Je vois la même chose pour le nom court PowerShell - c'est probablement bon pour le type de vitesse, mais cela peut vraiment poser un problème pour l'arborescence de répertoires (liens symboliques).

Une autre pensée. Doit-on penser au type de vitesse? Tous les cas proposés ne sont pas bons de ce point de vue.
La dernière réflexion concerne la prononciation. Intéressant, en russe, nous utilisons "пош" ("posh") et l'hypocorisme "пошик" ("poshik") depuis la naissance de PowerShell. Je suppose que tout homme russe votera pour "chic" ou "psh".

Pour être clair, pwsh ne serait pas un alias (en termes PowerShell), cela devrait être quelque chose que vous pouvez appeler à partir de cmd.exe ou d'un fichier de commandes tel qu'il existe physiquement. Bien que je ne sache pas comment nous implémentons réellement cela si nous voulons prendre en charge à la fois un nom court et powershell sans avoir deux exécutables (bien que poweshell.exe soit relativement petit ...).

En ce qui concerne posh et psh vs pwsh , la principale préoccupation avec posh et psh est qu'ils existent déjà (quelle que soit leur importance sont). Nous avons eu un problème au début avec notre alias curl car il était en conflit avec un outil natif existant et (peut-être sommes-nous trop prudents ici) nous essayons d'éviter une situation similaire avec la main courte, c'est pourquoi nous vous penchez vers pwsh . Peut-être que si je tape pwsh assez souvent les gens s'y habitueront :)

Autre côté. Comment résolvons-nous la même chose dans PowerShell? Nous suggérons aux utilisateurs des alias et IntelliSense pour amorcer la saisie.
Lorsque nous avons discuté des alias dans l'une des discussions ici, nous avons dit que tous les alias actuels ne devraient pas être en lecture seule - nous devrions permettre aux utilisateurs de supprimer / modifier les alias. En d'autres termes, les alias ne doivent pas être exclusivement standard. Seuls les noms d'applet de commande de base doivent être standard. De ce point de vue, il ne faut pas proposer un alias "standard" pour "powershell" - toute communauté ou distributif doit pouvoir choisir le nom qui lui plaît et qui correspond à son esprit, aussi ils pourraient proposer IntelliSense aussi.

@ SteveL-MSFT - Je pense que «pwsh» restera probablement très bien avec les gens.

Cela étant dit, vous avez mentionné l'incident de curl comme raison de ne pas utiliser «psh». Je trouve cela problématique car vous vous enfoncez simplement dans un coin en traçant des parallèles trop loin!

«curl» est l'un des outils les plus utilisés dans le monde Linux. Il est sage d'être trop prudent de ne pas répéter «curl» snafu pour un logiciel «vivant» / «actif» , mais pourquoi cette courtoisie devrait-elle être étendue à l' abandonware ?

Laissez l'incident curl nous enseigner une leçon, mais pas la mauvaise.

À l'appui des conseils de analyse précise de

Je voterais pour psh - le projet que vous citez comme une collision n'a pas été publié depuis 10 ans, et n'a en aucun cas été dans les dépôts de paquets.

En d'autres termes: le fait que psh faisait apparemment jamais partie des dépôts de paquets (majeurs) (j'ai seulement vérifié apt (Ubuntu, Debian) et yum (Fedora, RedHat)) - c'est-à-dire, a toujours été un _niche produit_ - _et_ qu'il peut à toutes fins utiles être considéré comme abandonné après plus de 10 ans d'inactivité en fait un candidat parfait.

(En revanche, le fait que posh soit toujours un package disponible via apt , quel que soit son statut de maintenance, le disqualifie, à mon avis.)

Je suis d'accord avec les points soulevés selon lesquels psh est une option viable et devrait être considérée

Quant à la manière de _implémenter_ le nom court en tant que lien symbolique / stub, en supposant que le nom de l'exécutable réel restera powershell[.exe] :

Supposons que le nom court sera, disons, psh (juste pour choisir l'un des noms discutés, au hasard).

Plateformes Unix

Le programme d'installation devra _en plus_ faire l'équivalent de ce qui suit:

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

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

En d' autres termes: créer un lien symbolique supplémentaire nommée psh que simplement des points à l'existant powershell symlink.

Sur macOS, cela entraînerait une chaîne de liens symboliques telle que la suivante:

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

Tout shell appelant, y compris PS Core lui-même, pourrait donc utiliser psh comme alternative plus courte à powershell .

les fenêtres

Sous Windows, les choses sont plus compliquées:

• au moins à partir de la version beta.7, à partir de _à l'extérieur_ de PS _Core_, il n'y a que _Windows_ PowerShell qui se trouve dans le PATH.
• Il devrait y avoir des raccourcis distincts pour Windows PowerShell vs Powershell Core pour un appel ciblé: psh pour PS Core et wpsh pour Windows PS (ce nom devrait également convenir, car il n'est pas non plus utilisé dans les apt et yum ).

Windows PS

_Windows_ PS pourrait définir des liens symboliques - un chacun dans $env:SystemRoot\System32\PowerShell\v1.0 (64 bits) et $env:SystemRoot\SysWOW64\PowerShell\v1.0 (32 bits) comme suit:

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

Du fait que $PSHOME se trouve dans le $PATH , tout shell, y compris PS Core et Windows PS lui-même, pourrait alors invoquer Windows PS en tant que wpsh .

PS Core

Le fichier abrégé en lui-même pourrait être placé dans un répertoire qui se trouve dans le PATH par défaut, ce qui permettrait l'invocation même sans $PSHOME PS Core lui-même dans le PATH.

Les considérations 64 bits contre 32 bits ne s'appliquent pas (PS Core est uniquement 64 bits), donc $env:SystemRoot (généralement, C:\Windows ) pourrait être choisi.

Malheureusement, l'utilisation de _ liens symboliques_ est au moins actuellement _pas_ une option, car PowerShell Core refuse de s'exécuter lorsqu'il est appelé via un lien symbolique qui a un nom différent:

À partir d'une session PS _élévée_:

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

L'appel de psh.exe échoue comme suit:

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 quelqu'un connaît un moyen de contourner ce problème, faites-le nous savoir.

(Curieusement, si vous définissez le lien symbolique _sans extension_ - psh au lieu de psh.exe - l'invocation réussit en principe, mais aucun paramètre n'est passé.)

Une solution de contournement consiste à utiliser un fichier de commandes de stub (encore une fois, exécuté à partir d'une session PowerShell _elevated_):

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

Tout shell appelant, y compris Windows PowerShell et PS Core lui-même, peut alors utiliser psh comme raccourci pour appeler PS Core.

@ mklement0 Je pensais la même chose en termes d'utilisation d'un lien symbolique sur Linux / macOS et d'un fichier batch pour Windows (et je ne ferais rien pour Windows PowerShell car cela resterait simplement powershell ).

Il semble que la chose la plus évidente soit que powershell est le principal et psh est le lien, mais je pensais peut-être que nous devrions inverser cela pour que psh soit le nom de l'exe et powershell est le lien. Le raisonnement est qu'avec un nouveau public non-Windows et pour se différencier de Windows PowerShell, il semble que la préférence soit que les gens utilisent psh pour faire référence à PowerShell Core et powershell est juste fourni pour app-compat (peut-être la mémoire musculaire pour certaines personnes lors de leur transition). Cependant, je sais que tout le monde n'est pas convaincu par cette idée.

Si nous voyons que psh très populaire, nous pouvons échanger powershell et psh .

Pour ajouter un alias, vous pouvez aider https://stackoverflow.com/questions/2016722/one-dll-multiple-projects

Je n'aime pas l'idée que psh devienne l'exe et que PowerShell soit relégué au rang de lien. Vous perdez 10 ans de fidélité d'audience pour une facilité d'utilisation potentielle sur des non-Windows où la taille de l'audience est inconnue et (au moins pour commencer) potentiellement petite.

Plus je vois de PowerShell v6, plus il semble que les utilisateurs Windows existants soient ignorés dans une tentative de convaincre les utilisateurs non Windows d'adopter PowerShell. Où se termine ce processus?

@RichardSiddaway Je n'ai pas l'impression que l'équipe PowerShell ignore du tout les utilisateurs Windows et je suis principalement un utilisateur Windows avec un Windows Phone. C'est moi qui ai demandé cela non pas par un concept Linux, mais par mes propres défis de passer de cmd à powershell.

Le fait est que Windows PowerShell est un produit mature mais non conçu pour les plates-formes multiples. Pour que cela fonctionne, l'investissement initial doit être plus élevé vers une multiplateforme au départ qui profitera aux deux mondes. Les choses s'équilibreront au cours des prochaines versions.

À part les alias et les alias de paramètres, je ne vois pas grand-chose qui ait un impact négatif sur les utilisateurs de Windows. S'il y a un problème spécifique qui vous préoccupe, veuillez le soulever dans ces questions. Le débat est bon pour la plate-forme et nous devons nous assurer que rien de spécial à propos de PowerShell ne se perd dans la transition.

@ SteveL-MSFT pouvez-vous fournir un peu plus de votre raisonnement pour que psh ou pwsh devienne le .exe? S'il y a des avantages qui en découlent, je serai peut-être plus enclin à le favoriser.

Aïe sur le fichier de commandes. Quoi qu'il en soit pour faire fonctionner le lien symbolique sur Windows? Je préfère avoir cela qu'une autre couche via cmd.

@ dragonwolf83 J'imagine powershell , il semble que dans une perspective à long terme, nous devrions optimiser pour la version plus courte

Vos commentaires sur Windows PowerShell sont parfaits.

@ dragonwolf83 :

Aïe sur le fichier de commandes. Un moyen de faire fonctionner le lien symbolique sous Windows?

Je t'entends. Hélas, mon appel à l'aide a reçu très peu d'attention jusqu'à présent.

powershell.exe est 78k, serait-il si mauvais d'avoir un autre 78k comme psh.exe ...

Avoir 2 exécutables dupliqués pourrait être une solution facile mais pourrait également prêter à confusion car je peux imaginer que les utilisateurs commenceront à se demander s'il y a une différence entre les 2. Si j'étais nouveau sur PowerShell et que je voyais 2 exemples différents (par exemple sur SO) montrer comment appeler / ouvrir PowerShell alors je commencerais immédiatement à me demander quel exemple je devrais choisir car je suppose qu'il y a une différence ...

OMI c'est idiot. cmd.exe est en grande partie caché dans Windows 10 1703, vous lanceriez donc rarement powershell.exe à partir du shell hérité.

Pas un grand fan de cela - à quelle fréquence tapez-vous powershell que cela devienne un problème? (En outre, problème total de bikeshed;)) Dans Windows 10 et Server 2016, définissez «Remplacer l'invite de commande par Windows PowerShell lorsque je clique avec le bouton droit sur le menu Démarrer ou appuyez sur Win + X» et c'est aussi court que Win + x, i ou sous Linux , ajoutez un alias à votre shell existant avec le nom que vous préférez.

Cela dit, qu'en est-il:

• ps1 - après l'extension de fichier sous Windows, court, facile à taper, mémorable
• psps - est court et typable, mais se laisse ouvert à l'argot `` typique M $ bloat ''
• ips - comme pour Invoke-PowerShell, il ne semble pas être un package dans les dépôts RedHat ou Ubuntu et yum provides "*/ips" ne montre aucun binaire avec lequel entrer en conflit dans une vérification rapide

Permettez-moi de vous poser la question suivante: est-ce que quelqu'un a une bonne raison de ne pas choisir pwsh?

C'est moche et imprononçable, prend plus de syllabes à dire que «powershell» lui-même, n'est pas particulièrement facile à taper et semble dériver de pwnd / pwnt en langage Internet.

Si nous allons bientôt avoir PowerShell comme shell par défaut sur Windows, le nom du fichier (longueur) devient sans importance.

PowerShell Core est un projet portable - nous devons également penser à Unix.

@ PowerShell / PowerShell-Committee a discuté de cela et où nous avons atterri, c'est d'avoir le binaire PSCore6 appelé juste pwsh sans raccourci / alias supplémentaire pour powershell . L'avantage est de le rendre explicite sans ambiguïté sous Windows, que vous utilisiez Windows PowerShell ou PowerShell Core. Sous Windows, il est plus court à taper et plus cohérent avec les autres noms de shell. En fonction des commentaires des clients, nous pouvons toujours ajouter un lien / raccourci / alias powershell à l'avenir.

Mon vote est psh.exe.

@jandrusk Le PR a déjà fusionné hier, ce sera donc pwsh.exe. Jeffrey a déjà tweeté à ce sujet ici .

Vive le nouveau PassWord / Par-Week / PoliceWoman SHell!

Mon vote aurait été de le laisser tranquille.

Alors, comment prononçons-nous pwsh?

pwsh
p. wush
p.woosh
puh.wush

Espérons que quelque chose de mieux que ceux

@jonathanmedd J'ai utilisé pwish comme wish avec un p .

Étant donné que _pwsh_ est un acronyme récursif (similaire à _GNU_) - S'il vous plaît, pourquoi pwSH? - Je suggère "pweesh", comme un lapin mignon avec un lisp en disant "s'il vous plaît".

Blague à part:

• Bien que je pense personnellement que s'installer sur pwsh était malheureux, je suppose que nous nous y habituerons bientôt et que nous n'y penserons plus.

• En ce qui concerne la prononciation: personnellement, je n'en vois pas la nécessité, étant donné que le nom complet est suffisamment court, et pour quiconque vit dans le monde de PowerShell, la cartographie sera évidente. (Un exemple du monde Unix: zsh se prononce apparemment zee shell ou zed shell , pas comme une seule syllabe).

P-Dub Shell ?

P Double U Shell ou P Double U S H est juste pénible à dire. Plus de syllabes que PowerShell mais vous voudrez probablement distinguer PowerShell de pwsh . Tout comme bash se distingue de Bourne-Again Shell .

vous voudrez probablement distinguer PowerShell de pwsh

En termes de noms complets officiels, c'est _PowerShell Core_ vs _Windows PowerShell_ - _PowerShell_ en lui-même peut faire référence à n'importe quelle édition.
Si ce n'est pas clair dans le contexte, l'ajout du qualificatif approprié éliminera l'ambiguïté - et ne sera peut-être pas nécessaire si souvent (par exemple, dans un contexte Unix pur).

À plus long terme, étant donné que PowerShell Core est l'édition qui fonctionne sur "toutes" les plates-formes, je ne serais pas surpris si _PowerShell_ devenait un raccourci commun et informel pour _PowerShell Core_ (le PowerShell "par défaut"), avec un qualificatif - _Windows_ - utilisé uniquement pour faire référence à l'édition Windows.

En aparté:

Tout comme bash se distingue de Bourne-Again Shell.

bash _est_ le _Bourne-Again SHell_ - il contraste avec son prédécesseur, le _Bourne SHell_ ( sh ,
avant que POSIX ne standardise le langage).

@ mklement0 Je parle de distinguer pwsh le binaire de PowerShell le langage / shell. Ne pas distinguer les différentes implémentations / plates-formes de PowerShell. Tout comme bash est utilisé pour distinguer le binaire de Bourn-Again SHell . Ils sont interchangeables, oui, mais lorsque vous avez besoin de distinguer les 2, vous avez besoin d'un moyen clair de prononcer pwsh .

pousser: sourire:

Alors peut-être:

p shell ou p w shell

@markekraus :

Ah, je vois, merci d'avoir clarifié.

Si vous voulez transmettre le nom _exact_ du binaire, aucune prononciation en dehors de _épeler_ le nom ne vous aidera (cela n'aurait fonctionné qu'avec quelque chose comme posh ).

Ainsi, faire référence au binaire / exécutable de PowerShell devrait fonctionner pour tous ceux qui sont déjà au courant, et pour d'autres, vous devrez le préciser de toute façon.

Si vous voulez transmettre le nom exact du binaire, aucune prononciation en dehors de l'épellation du nom ne vous aidera.

Nous devrons être d'accord pour être en désaccord sur celui-là 😃.

Je comprends votre _ désir_ que cela fonctionne - comme c'est le cas avec "bash" et "chic", par exemple - mais comme en témoignent vos propres luttes ci-dessus, cela ne fonctionne pas avec "pwsh" - qui, il est juste de supposer, nous suis coincé avec maintenant.

cela ne fonctionne pas avec "pwsh"

eh bien, pas avec cette attitude, ce n'est pas le cas! 😉 Je l'ai appelé pwish et je continuerai probablement de le faire. Mais je crée juste un dialogue pour voir si les autres proposent autre chose. push est bon compte tenu de la prononciation de w dans certaines langues. pwsh pas complètement irrémédiable, OMI. peut-être que tout le monde se contentera de p w s h . mais il est trop tôt pour dire "nous avons terminé ici" et considérer la question tranchée, l'OMI.

:)

Vous avez raison.

Je suppose que je me concentrais trop sur l'aspect de la transmission de l'orthographe exacte à quelqu'un qui n'est pas encore familier avec PowerShell plutôt qu'un nom court établi par convention pour ceux déjà au courant (qui savent déjà comment mapper ce nom court à pwsh ).

Qu'en est-il de MSPosh. Plus court que PowerShell.exe et respecte les normes, tout en servant également de nom amusant pour The PowerShell Hero ?

@ 1RedOne le héros / avatar PowerShell sera toujours PoSH-Chan dans mon ❤️

Il semble que l'équipe PWSH se précipite pour changer de nom. :-)

Je vote pour pscmd.exe

lors de la saisie de cmd dans Windows, cela devrait apparaître! et il remplace en fait le cmd ...

si c'est une question de mémoire musculaire, réglons ce problème.

si c'est juste pour le plaisir de lui trouver un nouveau nom sympa, alors ce devrait être pscore.exe, puisque c'est ce que c'est.

juste mes 2 cents.

pwsh , le shell fwremwst Wbject-Wriented du monde. Je suis lwwking fwrward tw nouvelles applets de commande continuant ce modèle:

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

;)

-

Ref prononciation, qu'en est-il de " powsh " dit comme "poche" ou "canapé" avec un "s" doux. (Pensez aux impressionnistes de Sean Connery qui disent «pochette»).

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.

Je suppose que ce message d'erreur est lié à ce problème. Comment puis-je réparer ça?

En ce qui concerne la question du nom, je vote pour pwsh, puisque Bash est le Bourne Again SHell.

Je vote pour PWSH. Et je le prononcerais comme push.
J'ai vu beaucoup de gens dans la communauté utiliser le chic, donc ce serait mon deuxième choix, même si je pense que MS essaie peut-être de ne pas l'appeler chic.

Je vote pour pwr !

@DaleMitchell comment avez-vous eu cette erreur? Si vous l'avez construit vous-même, avez-vous rechargé build.psm1?

J'ai vu beaucoup de gens dans la communauté utiliser chic

https://github.com/dahlbyk/posh-git par exemple.

pwsh se prononce posh . @SaschaNaz POSH existe déjà en tant que shell malheureusement

Ai-je manqué un vote @ PowerShell / PowerShell-Committee sur la façon dont il est prononcé? :)

Je pensais que nous pourrions peut-être le prononcer Microsoft Next Generation Command Line Interface Shell Experience 2017 , ou peut-être juste, vous savez, powershell .

Je ne l'utilise pas avant la sortie du Service Pack 2 de l'interface de ligne de commande Microsoft Next Generation Shell Experience 2017 ...

POSH existe déjà en tant que shell malheureusement

Ouais, ce sera TRÈS déroutant lorsqu'un utilisateur veut du chic, essaie sudo apt install posh et obtient ensuite un shell complètement différent.

BTW, poh-sh ou pah-sh ? Très certainement ce dernier?

Le nom du paquet est toujours PowerShell, aucun changement ici:

sudo apt install powershell

Un article rapide (avisé) sur l'état du débat:

• Quant au _nom de fichier du binaire_: la décision a été prise et rendue publique: pwsh c'est.

• Quant à la _prononciation_:

  • Il n'y en a aucun qui puisse transmettre l'orthographe exacte du binaire au _uninitiated_ - pas d'autre choix que de l'épeler.

  • Pour les _initiés_, "PowerShell" est sans doute tout ce qui est nécessaire, car il sera généralement clair d'après le contexte si l'on fait référence au _produit_ ou au _ nom de fichier du binaire_ (le souci de pwsh dans leur tête.
    Ajoutez «Core» et «Windows» pour lever l'ambiguïté, si nécessaire.

  • Inutile de dire que la quête passionnée du surnom informel définitif d'une syllabe se poursuivra ...
    Puisqu'un acte de mappage mental sur pwsh est nécessaire dans tous les cas, ceux établis de manière informelle tels que "Posh" peuvent tout aussi bien être utilisés.

À l'époque où nous utilisions MKS Toolkit pour la prise en charge des scripts multiplateformes, nous utilisions ksh.exe mais nous l'appelions toujours KornShell . Donc, même si le binaire est pwsh , je l'appellerai PowerShell.

Je pense que tout ce problème de "comment prononcez-vous le nom binaire" aurait pu être évité si le nom binaire avait été pwrsh mais que ce navire avait navigué.

Dans le «vieux temps» (est-ce qu'il y a 15 ans compte?), Mon équipe a appelé le binaire «kish», et «KornShell» était pour une discussion générale du shell.

Exemple:

"Tapez ooser bin kish puis appuyez sur Entrée. Vous êtes maintenant dans le KornShell"

il y a 15 ans compte-t-il?

C'est un peu relatif à la personne que je suppose. Mon expérience avec KornShell a commencé il y a 24 ans. Il y a 15 ans, ma fille était une petite fille et cela ne semble pas si longtemps. Yikes - le temps passe vite.

mon équipe a appelé le binaire "kish"

Je ne peux pas dire que je l'ai déjà entendu prononcer de cette façon. :-)

Je ne peux pas dire que je l'ai déjà entendu prononcer de cette façon. :-)

Oui. en dehors de cette équipe, il a toujours été "ksh" ou "KornShell". Mais c'est un peu le point: discuter de la façon dont les gens prononcent les lettres «pwsh» (absent de «PowerShell») et voir s'il y a un consensus. Ce n'est pas une discussion complètement sérieuse et rien ne sera jamais une prononciation officielle puisque c'est un mot imprononçable (aucun manque de respect destiné à l'équipe- push ). mais il a du mérite qu'un concurrent populaire l'emporte peut-être et nous commencerons à l'entendre dans les présentations.

Avant de travailler chez Microsoft, j'étais une personne Unix et j'ai toujours appelé ksh Korn Shell et csh C Shell. Je ne me souviens pas que quiconque à l'époque ait essayé de les prononcer comme des mots:

Quelqu'un pourrait-il expliquer de manière concise pourquoi un changement de rupture comme celui-ci a été apporté? Je suis hors de la boucle (clairement!), Et je discutais avec

J'ai fait ma lecture de rappel sur le processus de contribution tout à l'heure. Je pensais que cela nécessiterait une RFC au début, mais je peux voir comment cela peut ne pas s'appliquer. Ensuite, je regarde la politique sur les changements de rupture (https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md). Pouvez-vous nous dire dans quel seau ce changement est tombé, et ainsi de suite?

N'essayant pas de susciter quelque chose qui est clairement réglé, je veux juste pouvoir communiquer efficacement avec les autres intéressés qui ne vont pas lire les spécifications et les problèmes. Merci!

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

mon 2c. C'est un changement majeur. Trop de fichiers de commandes existants dans des scénarios de production sortants utilisent déjà powershell.exe pour lancer des scripts PowerShell. Je ne suis pas contre le fait de fournir une commande courte supplémentaire pour lancer le même exécutable, mais la suppression de «powershell» causera des ravages majeurs. Veuillez fournir un moyen d'utiliser les deux (alias ou autre)

@RudolfHenning Contrairement aux versions précédentes de Windows PowerShell, PowerShell Core fonctionnera côte à côte avec une autre version de lui-même et des versions plus anciennes de Windows PowerShell. Il doit y avoir un moyen d'appeler à la fois Windows PowerShell et le noyau PowerShell à partir de la ligne de commande et des scripts de commandes sans avoir à appeler le chemin complet de l'EXE prévu ou sans risquer l'ordre des chemins, ce qui entraîne powershell.exe appelant le mauvais version.

Même après la sortie de PowerShell Core 6.0, il sera toujours nécessaire d'utiliser Windows PowerShell (5.1 et versions antérieures) pour de nombreuses tâches centrées sur Windows, car de nombreux modules et scripts officiels et communautaires nécessitent un accès aux objets Full CLR non disponibles dans Core.

De plus, quiconque portera ses scripts des versions antérieures vers la 6.0 devra probablement faire des ajustements car il y a beaucoup de changements de rupture entre 5.1 et 6.0. Puisque le code devra de toute façon être touché, le lot peut être basculé vers pwsh.exe partir de powershell.exe . S'ils ne portent pas PowerShell Core, rien ne cassera et les scripts continueront de s'exécuter avec powershell.exe aide de Windows PowerShell.

Merci pour l'explication.
Comme j'utilise à la fois Windows et certains systèmes d'exploitation Linux, la compatibilité de mes scripts est parfois un problème - oui, je sais que les bibliothèques PowerShell sous Linux sont strictement encore bêta. J'ai investi beaucoup de temps et d'efforts dans la création de scripts pour mes machines Linux.
Quoi qu'il en soit, continuez à faire du bon travail!

Le runner Powershell de TeamCity suppose que l'exécutable s'appelle powershell . Puisqu'il n'y a pas de Powershell 5 sous Linux pour causer des problèmes de compatibilité, le paquet Linux aurait dû continuer à créer le lien symbolique powershell . C'était une casse inutile.

Qu'est-ce que je suis arrivé en avril? Allons-nous supprimer les voyelles des commandlets PowerShell ensuite? Cela doit être une blague.

les anciens scripts (docker) utilisant "powershell -command xxxx" ne fonctionnent plus avec la nouvelle version beta-9 ....

en attendant le shitstorm

Il y a beaucoup de raisons pour un changement de rupture sur l'endroit ou le point d'entrée "le plus important", mais raccourcir le nom de la commande de 6 octets et le rendre moins lisible n'en fait pas partie ...
à quelle fréquence dans le passé nous décidons d'utiliser un nom meilleur / plus long dans notre code car la lecture peut / doit être plus facile que l'écriture ...

garde mon 2cent
Cordialement
Werner

J'essaie de comprendre l'indignation et l'échec.

Les gens se plaignent que le nouveau nom brise les choses, mais PowerShell Core est toujours en version bêta. OMI, si quelqu'un utilise une technologie bêta dans le code de production, il invite au désastre (j'utilise un langage poli ici). La nature des versions alpha et bêta est celle d'être remplie de changements de rupture. Il n'y a aucune illusion que ce n'est pas une version bêta. beta est intégré au nom de la version: 6.0.0-beta.9 .

Ce changement de nom n'a aucun effet sur Windows PowerShell. Cela ne devrait pas casser ce que vous faites actuellement dans Windows. Si vous faites des choses sous Linux, vous devez reconnaître le fait que vous utilisez une version bêta, au lieu de blâmer la version bêta d'être une version bêta. Pensez à utiliser autre chose jusqu'à ce que la version stable soit RTM si vous ne pouvez pas gérer les changements de rupture entre les versions bêta.

Je comprends que les gens n'aiment pas le nom. Vous ne pouvez pas toujours obtenir ce que vous voulez. Personnellement, j'ai détesté PowerShell.exe car il est long et difficile à taper. pwsh est au moins moins de caractères pour moi de gâcher. Si vous regardez le fil de discussion, vous pouvez voir que plusieurs options ont été discutées, certaines d'entre elles bien pires (IMO) que pwsh .

Les gens comprennent mal cela comme une tentative maladroite de se fondre dans les enfants Linux cool, alors que l'un des principaux facteurs de motivation pour un nouveau nom binaire est lié à Windows. Oui, un nom linux-y a été choisi, mais devinez quoi? PowerShell est désormais également un citoyen * nix. Je pense qu'il est temps que les gens s'habituent à ce fait. L'un des objectifs de Core est la portabilité multiplate-forme, donc oui, les décisions peuvent et seront prises avec plus que Windows à l'esprit.

c'est donc ma valeur de 2 cents.

L'un des objectifs de Core est la portabilité multiplateforme

Une partie de la portabilité multiplateforme est que les mêmes commandes devraient fonctionner sur les deux plates-formes si elles font la même chose. Avant ce changement, je pouvais exécuter powershell quel que soit le système d'exploitation que j'utilisais et obtenir la bonne chose. Maintenant, je ne peux plus faire ça.

Créer un logiciel facile à utiliser signifie prendre soin d'un million de petites choses. L'utilisation de noms étranges et peu intuitifs va à l'encontre de cela.

Je pourrais exécuter powershell quel que soit le système d'exploitation que j'utilisais et obtenir la bonne chose. Maintenant, je ne peux plus faire ça.

Pas précis. Vous pouvez exécuter powershell sous Windows et obtenir Windows PowerShell, puis exécuter powersehll sous Linux et obtenir PowerShell Core. Vous pouvez maintenant exécuter pwsh sous Windows ou Linux et obtenir PowerShell Core. Alors MAINTENANT, nous sommes dans l'état que vous désirez. où, comme avant, nous étions dans un état incohérent.

L'utilisation de noms étranges et peu intuitifs va à l'encontre de cela.

et bien c'est clair ce n'est pas universellement apprécié, mais ... quelle alternative suggérez-vous? Je vois tout le monde se plaindre du nom mais aucune alternative au problème sous-jacent auquel ce changement de nom ne répond. Comme je l'ai dit "Vous ne pouvez pas toujours obtenir ce que vous voulez"

Quel que soit le nom choisi, les gens seraient malheureux.

@markekraus

• nous savons que c'est une version bêta - les changements de rupture sont ok!
• Je suis un grand fan de l'amélioration de PS sur * nix car cela m'aide à transférer mes connaissances (PS) de Windows vers * nix

Mes commentaires portaient sur la convivialité et l'inquiétude d'un shitstorm qui impose à nouveau des renominations et des discussions sans fin.

Vous pouvez exécuter PowerShell sur Windows et obtenir Windows PowerShell, puis exécuter powersehll sur Linux et obtenir PowerShell Core. Vous pouvez maintenant exécuter pwsh sur Windows ou Linux et obtenir PowerShell Core. Alors MAINTENANT, nous sommes dans l'état que vous désirez. où, comme avant, nous étions dans un état incohérent.

Séparer Windows et Core est vraiment une MEILLEURE raison pour le renommer alors "Créer un nom plus court"!

Je suggère de faire des communications plus claires à ce sujet (titre du problème, notes de publication, etc.)
J'ai lu les 2-3 premières pages de ce numéro et la discussion ne portait que sur la longueur ...

autres commentaires:
Au cours des dernières semaines, j'ai fait beaucoup de codages avec PS-Core sur Docker et * nix
Je l'aime bien mais a besoin d'un peu de polissage.
Idée / Suggestion:
si le nom est changé de Powershell à pwsh, pourquoi ne pas changer la version de 6.0 à 1.0 (même discussion comme la transformation de ".Net 5.0" en "dotnet core 1.0
Fondamentalement, CORE ressemble plus à une version 1.0 qu'à une version 6, spécialement sur * nix !!

Cordialement
Werner

@WernerMairl Il y a une discussion ouverte sur l'utilisation de 1.0 au lieu de 6.0.0 # 5165. Veuillez accéder à ce fil de discussion et lire et commenter.

De plus, étant donné que vous l'utilisez et que vous avez rencontré des choses dont vous pensez avoir besoin d'être peaufinées, veuillez vérifier les problèmes en suspens pour voir s'ils traitent de ce que vous avez rencontré. S'il y a un problème en suspens, votez dessus ou commentez et si ce n'est pas le cas, ouvrez un nouveau problème afin qu'il puisse être résolu. Plusieurs d'entre nous, membres de la communauté, sont activement engagés dans la résolution des problèmes de priorité inférieure et l'équipe Microsoft a fait un travail incroyable en traitant les problèmes les plus prioritaires et les plus difficiles. De plus, il n'est jamais trop tard pour devenir vous-même contributeur!

En ce qui concerne la description du problème et la communication du changement, je conviens qu'il y avait place à l'amélioration sur la communication de ce changement et pourquoi il était nécessaire. Les rôles de différentes personnes dans ce référentiel peuvent être un peu déroutants, mais je ne fais pas partie de l'équipe PowerShell, juste un contributeur de la communauté avec (essentiellement) des privilèges de modération de forum. Je ne peux pas parler au nom de l'équipe PowerShell, mais je soupçonne qu'ils comprennent ce fait eux-mêmes.

Pour leur défense, celui-ci est un peu difficile à communiquer. La majorité des plaintes semblent provenir du manque de compréhension des similitudes et des différences entre Windows PowerShell et PowerShell Core. Afin de communiquer efficacement ce changement, ils auraient également eu besoin de reformuler ce qui était énoncé dans l' article du blog du 14 juillet . Et même alors, les gens ont encore du mal à naviguer dans les similitudes et les différences. Je pense qu'il faudrait une longue description de la raison pour laquelle le changement de nom a été fait que beaucoup ne liraient toujours pas. Je soupçonne que les torches et les fourches seraient venues quoi qu'il arrive.

Pas précis. Vous pouvez exécuter PowerShell sur Windows et obtenir Windows PowerShell, puis exécuter powersehll sur Linux et obtenir PowerShell Core. Vous pouvez maintenant exécuter pwsh sur Windows ou Linux et obtenir PowerShell Core. Alors MAINTENANT, nous sommes dans l'état que vous désirez. où, comme avant, nous étions dans un état incohérent.

Je comprends ce que tu veux dire mais je rétorque que ce n'est pas ce que je veux. Il y a une hypothèse cachée implicite dans ma déclaration: je m'attends à ce que PowerShell et PowerShell Core soient complètement équivalents tant que j'utilise des fonctionnalités communes. Jusqu'à présent, cela s'est passé sans problème dans tous mes cas d'utilisation.

@sandersaares Je pense que votre expérience est celle de la chance. Cela ne correspond certainement pas à mon expérience. De plus, je pense que cette hypothèse est dangereuse. Il s'agit d'une version majeure avec une tonne de changements de rupture documentés avec une plate-forme sous-jacente complètement différente. Cela ne ressemblera pas aux versions principales précédentes de PowerShell avec une compatibilité ascendante de près de 100%.

Je vois que certaines personnes font encore la fausse hypothèse que le changement du nom de l'exécutable était principalement pour économiser sur la frappe. Je peux voir comment les gens ont pu avoir cette impression puisque ce numéro original qui a été utilisé pour le PR a commencé avec un titre demandant un nom plus court.

Je conviens que nous pouvons améliorer notre communication car nous ne devons pas nous attendre à ce que tout le monde lise tous les commentaires que le Comité fait sur les décisions. Surtout sur un sujet controversé comme celui-ci où le résumé de la décision se perd facilement.

Il semble également qu'il y ait un malentendu fondamental sur ce qu'est PowerShell Core 6, en particulier par rapport à Windows PowerShell. Windows PowerShell 5.1 est toujours et sera la version intégrée de PowerShell sur Windows. Mon équipe continue également de le soutenir au besoin. Nous nous attendons à ce que les clients continuent à compter sur Windows PowerShell aussi longtemps qu'ils en ont besoin, ce qui pourrait très bien être au moins dans les 10 prochaines années. Je pense que ce n'est que récemment que les téléchargements de WMF5.1 ont finalement dépassé les téléchargements de WMF4.0.

PowerShell Core 6 est la prochaine évolution de PowerShell où il est non seulement multiplateforme mais également Open Source. Comme l'a noté @markekraus , il s'agit d'un changement de version majeur qui nous a permis d'accepter des modifications de rupture que nous ne considérerions jamais pour Windows PowerShell. Notez également que PowerShell Core 6 est explicitement conçu pour fonctionner côte à côte (non seulement avec Windows PowerShell mais avec d'autres versions de PSCore6). Il ne devrait y avoir aucune ambiguïté sur ce que vous obtenez sous Windows lorsque vous tapez powershell . Je vais juste noter ici que la discussion 6.0 vs 1.0 a déjà eu lieu il y a longtemps avant que nous ne devenions public et qu'elle ne sera probablement pas rouverte.

@ SteveL-MSFT un article de blog sur le changement de nom serait bien. Il pourrait couvrir le pilote principal pour savoir pourquoi le nom change avec un exemple clair du problème sous Windows. Il serait également bon d'expliquer pourquoi chic et psh n'ont pas également fait la coupe.

Peut-être configurer "powershell" comme alias pour pwsh lors du déballage + installation. Cela vient de casser une version sur laquelle je travaillais pendant quelques jours jusqu'à ce que je trouve ce problème.

Edit: sur Linux

@markekraus a un joli article de blog qui capture le quoi et le pourquoi:

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

Aujourd'hui, j'ai vu la première utilisation de pwsh sur SO ici même si je doute que la personne connaisse ce fil ...

Pouvons-nous obtenir une décision officielle sur la prononciation de pwsh ? La spécification PNG inclut une prononciation dans sa section 1. Peut également en fournir une pour PowerShell; Je ne veux pas d'une autre situation SCSI «scuzzy» / «sexy».

On dirait "caca" pour moi.

@apjanke la prononciation généralement acceptée de pwsh est posh

Travaille pour moi. Merci pour la confirmation officielle!

Quant aux prononciations alternatives: ^[1]

• _Pish Posh!_

• _Poppyposh! _

• _Le Shell anciennement connu sous le nom de PowerShell_ (_TSFKAP_ en géorgien )

• _Le Shell qui n'ose pas prononcer son nom (car le nom de son exécutable est impononçable) _ (préféré par les gallois ).

^{[1] [Parodie.}