Powershell: 创建pwsh作为调用powershell.exe的简称

我想一个简短的别名太多，但这个就是为什么我们没有一起去posh时，我们先出去了（因为我们谈论的长度）。 似乎还是最新的软件包。

可以接受其他建议，但大多数明显的* sh都已采用。 在唯一的wget / curl别名之后，我真的想避免与其他软件包冲突，即使它们不太常见。

我对整个想法不是很疯狂，但是pwsh呢？

我从不热衷于将Powershell简化为时髦的东西。 pwsh似乎更好，但是快速的Internet搜索会引发一些可能的问题。 如果我们要这样做，我建议尽可能短，那么ps呢？

好的-忘记了-我刚刚意识到ps是get-process的别名。 那太令人困惑了

我现在越来越坚强。 😉

我感谢PowerShell的可读性（当不使用别名时），因此运行powershell对我来说很好。

ps也是Linux上的现有命令。

其他一些想法是： pscmd ， psc ， monad ， psh ， pshell

这些名称的收益肯定会递减，尽管它们是否确实保存了任何东西，或者即使它们可用，也只会增加不必要的混乱。

CoreSh ， pcs ， psc

太糟糕狂舞取。 使用psh 。 [pshell]返回许多匹配。 有趣的是，在Bing和Google上搜索msh为PowerShell（称为Microsoft Shell）带来很多成功，尽管在Unix上存在msh （也许使用不多）

😄S＃，P＃

@ PowerShell / powershell-committee对此进行了讨论，并且可以使用较短的符号链接名称，但是我们不能蹲在已经存在的任何人身上。 prsh似乎还可以。

等等！ 我知道了： ^sh -还是那个**sh ？ （jk）。

prsh似乎是原因-比pwsh更容易键入，尽管pwrsh -尽管是1个字符。 更长-值得考虑，因为“ pwr”是“ power”的已知缩写。

另一个可能是_complementary_选项：提供一个_automatic variable_，其值_invariably_反映启动当前会话的二进制文件的完全相同的路径。

bash具有$BASH 。

这种方法的优点是它不受$env:PATH /操纵变化的影响。

我们已经有$PSHOME -可以说，像$PS这样的东西并不是很大。

就是说，这涉及到有关不使用自动变量污染全局名称空间的讨论-参见＃4216。

.Net Core，CoreFX，CoreCLR，PowerShell Core-我们可以将“ core”视为基础。

pscore对我来说似乎很好，即使它没有以sh结尾，尽管委员会其他成员也否决了它

pscore或coreps -LGTM。

我们可以记住monad和msh （如上所述）。

我最喜欢pwrsh 。 pscore也不错，尽管它在6个字符时有点长。 四个或更少的字符可能是理想的选择，但我可以忍受pwrsh要求的5个字符。

我对合并“核心”一词的担心是，它在Unix平台上没有任何有用的信息，在该平台上，没有其他版本需要与之区分开。

@rkeithhill pscx怎么样，哈哈！ PowerShell核心体验。 但是，这的确使我想到了另一个pscsh PowerShell PowerShell Shell。

我自己被一些同名的人撕裂了。 我喜欢pwrsh和pscore的可读性，但我同意限制为5个字符。 5个字符覆盖第一个单词power并且除此以外，您还可以键入完整的内容。 monad是一个很棒的复活节彩蛋，可读性强，但对于那些不了解PowerShell背景的人来说却令人困惑。 4个字符prsh可以很好地工作。

提出一个可以使用的最终名称列表，并像Edge团队一样进行正式民意调查会很好。 如果有任何即将推出的PS社区或官方活动，可以提供指向民意调查的链接，以尝试吸引更多的受众。

@ dragonwolf83 ：

pscsh危险地接近csh -我们应该避免的关联。

再说一次，我看不到包含“核心”一词的好处，尤其是如果有一天这些版本可能统一的话（在_Windows_上，人们似乎过着舒适的生活，并且没有_Windows PowerShell_的简称已有好十年了） 。

同意对monad模糊处理。

我个人的投票是pwsh ， prsh或pwrsh 。

PS：如果_Windows PowerShell_也需要一个短名称，可以简单地以w开头作为解决方案，尽管在我的最爱中，实际上只有（合理地）以wprsh从键盘上滚下来，所以在对于两版短名称方案，我的投票是对prsh / wprsh对。

我对合并“核心”一词的担心是，它在Unix平台上没有任何有用的信息，在该平台上，没有其他版本需要与之区分开。

:-)我们应该重命名.Net Core吗？

@iSazonov ：我们是否应该将Windows PowerShell重命名为“ Windows PowerShell .NET Framework [FullCLR]”？

我会投票给psh -您引用的碰撞项目在10年内没有发布，而且无论如何都没有打包回购。

@Jaykul ：

psh ？ 我不知道-如果您要求我，则需要更多的“核心”。

顺便说一句：关于项目状态以及打包存储库中没有项目的极好信息。

psh也有我的投票（对于Windows PowerShell，也有wpsh ）。

（分别称为“ pshaw”和“ whiplash”）。

psh也有我的投票（对于Windows PowerShell，也有wpsh ）。
（分别称为“ pshaw”和“ whiplash”）。

您确定我们不能只在Windows上使用posh并发音为pish posh吗？ 🤡

Pish-tosh！ 对于整个杂烩来说，这太杂了。 🤡

我会投票给psh-您引用为碰撞的项目十年来都没有发布，而且无论如何都没有打包回购。

没有copywrite问题？

没有版权问题？

我希望真正知道的人能参与进来，但是我的猜测是，由于以下两个原因，这不会成为问题：

• psh不是正式的产品名称，只是一个缩写（更宽松地说，首字母缩写），仅是一种技术帮助（尽管在流行的用法中，它最终可能会成为产品全名的常用缩写；这是可能的）商标首字母缩写词/缩写词）。

• 商标问题通常与现有商标发生_confusion_的可能性有关，从我们在这里看到的情况来看，至少在软件领域似乎没有冲突（我不认为实际上已经废止的现有psh的创建者psh提起法律诉讼）。

如果有人想尝试/需要一个临时解决方案：

这是一个全别名解决方案，它在所有受支持的平台上定义PowerShell内部和外部的别名：PS Core的psh和Windows PowerShell的wpsh 。

• 运行一次下面设立的PowerShell的别名之外（ cmd.exe在Windows上，为bash在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"
  }
}

• 将以下内容放入$PROFILE以在PowerShell中定义相同的别名-在PS Core和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"
  }

那么Paua呢？ 这是对美丽的paua贝壳（来自新西兰的贝壳）的引用。 否则我认为psh也很好。

您从（新）西兰海岸出售贝壳吗？ （开个玩笑。确实很漂亮。）

免责声明：以下内容仅对[爱好]语言学家有用。

在语音上， paua仅适用于英语的非rhotic方言（例如，UK，NZ，Australia）。

还有波士顿人。

@ PowerShell / powershell-committee应该在beta.8上关闭

Posh6怎么样

Posh6怎么样

这样的感觉比将版本号放入文件扩展名快过时了...;）

是的，但是启动它的shell脚本将知道它正在运行的版本。

尽管我喜欢posh ，但我认为主要要担心的是已有一个名为Posh的Linux软件包，为避免发生另外的curl事件，我认为下一个最佳选择是pwsh

我喜欢pwsh 。 十年前真是太好了。 我想念msh 。

我投票给psh 。
gnp / psh在近5年内尚未承诺。 它也可能是废弃软件。

我讨厌这样说，但这是很难达成强烈共识的事情之一。 ：\

在这一点上，为了结束事情，并避免任何形式的冲突（比法律更“真诚”），我全神贯注于pwsh 。

让我这样问：有人有充分的理由不选择pwsh吗？

如果pwsh是可执行文件的名称， powershell是符号链接/快捷方式，会有人担心吗？

在这里进行任何批准之前，我们应该回答什么是“当前”版本，以及我们将如何引用它及其目标版本？

@iSazonov不确定我是否理解您的问题。 如果您要问的话，这与powershell -v N无关。 这只是允许使用pwsh代替powershell （尽管我们仍然支持拼写powershell ）。

我更关心的是像powershell-> powershell-6.0.0-beta.7这样的符号链接
如果说语言，我们喜欢在交互式会话中使用别名，因为它为我们提供了一个舒适的环境，但是别名在脚本中令人头疼。 我对powershell短名称有相同的看法-可能对速度类型很有用，但对于目录树（符号链接）可能确实是个问题。

另一个想法。 我们应该考虑速度类型吗？ 从这个角度来看，并非所有建议的案例都是好的。
最后想到的是发音。 有趣的是，自PowerShell诞生以来，在俄语上，我们使用“пош”（“ posh”）和虚伪主义“пошик”（“ poshik”）。 我想任何俄罗斯人都会投票赞成“ posh”或“ psh”。

只是要清楚一点， pwsh并不是别名（以PowerShell术语），应该是您可以从cmd.exe或实际存在的批处理文件中调用的名称。 虽然我不清楚我们是否要在不具有两个可执行文件的情况下同时支持短名称和powershell （尽管poweshell.exe相对较小...），但实际上如何实现此功能。

至于posh和psh与pwsh ，与posh和psh主要关系是它们已经存在（无论它们有多突出）是）。 我们早期使用curl别名遇到了问题，因为它与现有的本机工具冲突，并且（也许我们在这里过分谨慎）我们正试图避免用短手遇到类似情况，这就是为什么我们倾向于pwsh 。 也许如果我输入pwsh经常会被足够多的人习惯:)

另一边。 我们如何在PowerShell中解决相同问题？ 我们建议用户使用别名和IntelliSense作为输入的种子。
在此处的讨论之一中讨论别名时，我们说所有当前别名都不应该是只读的-我们应该允许用户删除/更改任何别名。 换句话说，别名不应仅是标准的。 仅基本cmdlet名称必须是标准名称。 从这个角度来看，我们不应该为“ powershell”提供“标准”别名-任何社区或发行者都应该能够选择他们喜欢的名称，并与他们的精神相对应，他们也可以提供IntelliSense。

@ SteveL-MSFT-我认为“ pwsh”可能会很好地贴在人们身上。

话虽如此，你们提到卷发事件是不使用“ psh”的原因。 我发现这很成问题，因为您只是通过将平行线画得太远而使自己（我们）陷入困境！

“ curl”是linux世界中最常用的工具之一。 明智的做法是不要对“活动” /“活动”软件重复使用“ curl” snafu，但是为什么要将此礼貌扩展到放弃软件呢？

让卷曲事件教给我们一个教训，只是没有错。

为了支持@AdilHindistan的建议，让我重申@Jaykul的重点分析（该线程已经很长，很难跟踪）：

我会投票给psh-您引用为碰撞的项目十年来都没有发布，而且无论如何都没有打包回购。

换句话说： psh似乎从来都不是（主要）软件包存储库的一部分（我只检查了apt （Ubuntu，Debian）和yum （Fedora， RedHat））-即始终是一种“小众产品”，并且在10多年的不活动使其成为理想的候选人之后，就其所有意图和目的而言，它都可以被认为是废弃的。

（相比之下，我认为posh仍然是可以通过apt获得的软件包，而不论其维护状态如何，这使我失去了资格。）

我同意以下观点： psh是一个可行的选择，应该考虑

至于如何将短名称作为符号链接/存根实现，假设实际可执行文件的名称仍为powershell[.exe] ：

假设短名称为psh （只是随机选择其中一个讨论的名称）。

Unix平台

安装程序将不得不执行以下等效操作：

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

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

换句话说：创建一个名为psh的附加符号链接，该符号链接仅指向现有的powershell符号链接。

在macOS上，这将导致符号链接链，如下所示：

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

因此，任何调用Shell（包括PS Core本身）都可以使用psh作为powershell的更短替代方案。

视窗

在Windows上，情况更加复杂：

• 从PS _Core_的_outside_起，至少从beta.7开始，只有_Windows_ PowerShell才在PATH中。
• 应该有适用于Windows PowerShell对PowerShell核心不同的速记进行有针对性的调用： psh为PS Core和wpsh对于Windows PS（这个名字应该也没关系，因为它也不能使用在apt和yum库中）。

Windows PS

_Windows_ PS可以定义符号链接-在$env:SystemRoot\System32\PowerShell\v1.0 （64位）和$env:SystemRoot\SysWOW64\PowerShell\v1.0 （32位）中各一个，如下所示：

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

由于$PSHOME位于$PATH ，因此任何外壳程序（包括PS Core和Windows PS本身）都可以将Window PS作为wpsh调用。

PS核心

速记文件本身可以放在默认情况下位于PATH的目录中，即使PS Core的$PSHOME本身不在PATH中，也可以允许调用。

64位与-32位的注意事项不适用（PS Core仅适用于64位），因此可以选择$env:SystemRoot （通常C:\Windows ）。

不幸的是，使用_symbolic links_至少目前不是_not_一个选项，因为通过具有不同名称的符号链接调用PowerShell Core时，PowerShell Core拒绝运行：

在_elevated_ PS会话中：

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

调用psh.exe失败如下：

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.

如果有人知道解决方法，请告诉我们。

（奇怪的是，如果您定义符号链接_without extension_- psh而不是psh.exe -调用原则上可以成功，但不会传递任何参数。）

一种解决方法是使用存根批处理文件（同样，从_elevated_ PowerShell会话运行）：

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

然后，任何调用Shell（包括Windows PowerShell和PS Core本身）都可以使用psh作为调用PS Core的简写。

@ mklement0在考虑在Linux / macOS上使用符号链接和Windows的批处理文件时，我在想同样的事情（对于Windows PowerShell，我不会做任何事情，因为那样只会保持powershell ）。

似乎最明显的是powershell是主要的，而psh是链接，但是我在想，也许我们应该翻转一下，以便psh是exe和powershell是链接。 原因是，在非Windows上有新的受众并且与Windows PowerShell有所区别时，似乎首选是人们使用psh来指代PowerShell Core，而只是提供了powershell app-compat（也许某些人在过渡时会记忆肌肉）。 但是，我知道并不是每个人都对这种想法感到满意。

如果我们看到psh非常受欢迎，我们可以交换powershell和psh 。

对于添加别名可能是帮助https://stackoverflow.com/questions/2016722/one-dll-multiple-projects

不喜欢将psh变成exe并将PowerShell降级为链接的想法。 您将失去10年的观众忠诚度，因为他们可能会在非Windows上轻松使用，因为非Windows的观众人数未知并且（至少一开始）可能很小。

我对PowerShell v6的了解越多，似乎在试图说服非Windows用户采用PowerShell时，现有的Windows用户被忽略的情况就越多。 这个过程在哪里结束？

@RichardSiddaway我没有得到PowerShell团队完全忽略Windows用户的印象，我主要是使用Windows Phone的Windows用户。 我是要求这样做的人，不是出于某种Linux概念，而是出于我自己从cmd转向Powershell的挑战。

事实是，Windows PowerShell是一个成熟的产品，但在构建时并没有考虑跨平台。 为了使这项工作奏效，从一开始就必须加大跨平台的初始投资，这将使双方都受益。 在接下来的几个发行版中，一切都会变得平淡。

除了别名和参数别名，我看不出有多少负面影响Windows用户的信息。 如果有一个特定的问题值得关注，请在这些问题中提出。 辩论对平台有利，我们需要确保在过渡期间不会丢失任何有关PowerShell的特殊问题。

@ SteveL-MSFT您能否提供更多使psh或pwsh成为.exe的理由？ 如果从中获得利益，我可能会更倾向于它。

批处理文件上的内容过多。 无论如何，使符号链接在Windows上工作？ 我宁愿通过cmd拥有另一层。

@ dragonwolf83我想随着时间的推移，人们会更喜欢输入3或4个字符而不是10个字符，因此尽管我们将始终支持输入powershell ，但从长远来看，我们应该针对较短的版本进行优化

您对Windows PowerShell的评论就在现场。

@ dragonwolf83 ：

批处理文件上的内容过多。 有什么方法可以使符号链接在Windows上工作？

我听到你了 las，到目前为止，我所寻求的帮助很少受到关注。

powershell.exe是78k，像psh.exe那样拥有另一个78k会很糟糕...

拥有2个重复的可执行文件可能是一个简单的解决方案，但也可能导致混乱，因为我可以想象用户将开始思考2个文件之间是否存在差异。显示如何调用/打开PowerShell，然后我将立即开始怀疑应该选择哪个示例，因为我认为存在区别...

海事组织这很愚蠢。 cmd.exe在Windows 10 1703中基本上是隐藏的，因此您很少会从旧版shell中启动powershell.exe。

不大喜欢它-您经常输入powershell成为问题吗？ （也是，彻底解决问题；））在Windows 10和Server 2016中，设置“当我右键单击开始菜单或按Win + X时，使用Windows PowerShell替换命令提示符”，它与Win + x，i或Linux一样短。 ，使用您喜欢的名称向现有外壳添加别名。

也就是说，那又如何：

• ps1 -Windows上的文件扩展名后，简短，易于键入，令人难忘
• psps -简短可输入，但对“典型的M $膨胀” at语开放
• ips -就好像Invoke-PowerShell一样，它似乎不是RedHat或Ubuntu仓库中的软件包，而yum provides "*/ips"显示没有二进制文件可以快速检查

让我这样问：有人强烈反对不使用pwsh吗？

它很丑陋且不发音，比“ powershell”本身要用更多的音节说出来，也不是特别容易输入，并且看起来像是源于互联网的pwnd / pwnt。

如果我们很快将PowerShell作为Windows上的默认外壳，则文件名（lenght）变得不再重要。

PowerShell Core是可移植项目-我们也必须考虑Unix。

@ PowerShell / powershell-committee对此进行了讨论，我们登陆的地方是使PSCore6二进制文件仅称为pwsh而没有powershell的其他快捷方式/别名。 这样做的好处是，无论您使用Windows PowerShell还是PowerShell Core，它在Windows上都不会引起歧义。 在非Windows上，它的键入时间较短，并且与其他外壳程序命名更一致。 根据客户的反馈，我们以后总是可以添加powershell链接/快捷方式/别名。

我的投票是psh.exe。

@jandrusk该PR已在昨天合并，因此它将是pwsh.exe。 杰弗里（Jeffrey）已经在这里发表推文。

新密码/每周/女警长命万岁！

我的表决将是不理它。

那么我们如何发音pwsh？

w
布什
伍什
h

希望比那些更好

@jonathanmedd我一直在使用pwish像wish和p 。

鉴于_pwsh_是递归首字母缩写词（类似于_GNU_）-请，为什么要使用pwSH？ -我建议使用“ pweesh”，就像一个可爱的兔子，上面有一个口齿不清的“请”。

开个玩笑：

• 虽然我个人认为在pwsh上定居是不幸的，但我认为我们会很快适应并且不会再考虑它。

• 至于发音：鉴于全名足够短，对于个人而言，我个人认为并不需要一个，对于住在PowerShell中的任何人，映射都是显而易见的。 （来自Unix世界的示例： zsh显然发音zee shell或zed shell ，而不是单个音节）。

P-Dub Shell ？

P Double U Shell或P Double U S H很难说。 比PowerShell音节更多，但您可能希望将PowerShell与pwsh区分开。 就像bash与Bourne-Again Shell是有区别的一样。

您可能想将PowerShell与pwsh区分开

就正式全名而言，它是_PowerShell Core_与_Windows PowerShell _-_
如果从上下文中不清楚，则添加适当的限定符将消除歧义-可能并不需要那么频繁（例如，在纯Unix上下文中）。

从长远来看，鉴于PowerShell Core是可在“所有”平台上运行的版本，如果_PowerShell_成为带有限定符-_Windows_的_PowerShell Core_（“默认” PowerShell”）的通用非正式缩写，我不会感到惊讶。仅用于指Windows版本。

作为旁白：

正如bash与Bourne-Again Shell一样。

bash是_Bourne-Again SHell_-与它的前身_Bourne SHell_（ sh ，
在POSIX标准化语言之前）。

@ mklement0我正在谈论区分pwsh二进制文件和PowerShell语言/外壳程序。 不区分PowerShell的不同实现/平台。 就像bash用来区别Bourn-Again SHell的二进制文件一样。 它们是可以互换的，是的，但是当您需要区分2时，需要一种清晰的方法来发音pwsh 。

推：微笑：

所以也许：

p shell或p w shell

@markekraus ：

嗯，我明白了，谢谢您的澄清。

如果您要传达二进制文件的_exact_名称，则缺少_spelling out_名称的发音将对您有所帮助（这只能与posh类的东西一起使用）。

因此，引用_PowerShell binary / executable_应该适用于所有已知人员，而对于其他人员，无论如何都必须将其拼写出来。

如果您想传达二进制的确切名称，那么只要拼写清楚该名称的发音就对您有所帮助。

我们必须同意不同意这一点。

我了解您的_desire_可以正常工作-例如，它与“ bash”和“ posh”一样-但由于您自己在证明方面的挣扎，因此不适用于“ pwsh”-可以肯定地说，我们现在被困住了。

它不适用于“ pwsh”

好吧，不是那种态度就没有！ 😉我一直将其称为pwish并且可能会继续这样做。 但是我只是创建一个对话，以查看其他人是否提出其他建议。 考虑到某些语言中的w发音， push是一个很好的选择。 IMO， pwsh并非完全不可弥补。 也许每个人都会选择p w s h 。 但现在就说“我们在这里完成了”并考虑已解决的问题还为时尚早，IMO。

:)

你是对的。

我想我把重点放在向尚未熟悉PowerShell的人传达_exact拼写_而不是为已经知道的人（由Convention_建立的简称）（他们已经知道如何将该短名称映射到pwsh传达_exact拼写_的方面。

MSPosh呢？ 比PowerShell.exe短，并且遵循标准，同时还可以作为PowerShell Hero的有趣名称加倍。

@ 1RedOne PowerShell英雄/头像将始终是我的❤️中的PoSH-Chan

看来PWSH团队正急于更改其名称。 :-)

我投票给pscmd.exe

在Windows中键入cmd时，它实际上应该显示出来！ 它实际上是在替换cmd ...

如果这是肌肉记忆的问题，让我们解决该问题。

如果只是为了找一个好名字而好玩，那么它应该是pscore.exe，因为它就是这个意思。

只是我的2美分。

pwsh ，wwrld的fwremwst Wbject定向的shell。 我正在继续使用这种新模式的两个cmdlet：

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

;）

-

ref的发音是什么，“ powsh ”

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.

我猜这条错误消息与此问题有关。 我该如何解决？

至于实际的名称问题，我投票赞成pwsh，因为Bash是Bourne Again SHell。

我投票支持PWSH。 我将其发音为“ push”。
我在社区中看到了很多使用posh的东西，这将是我的第二选择，尽管我认为MS可能正试图摆脱使用posh的想法。

我投票给pwr ！

@DaleMitchell您是怎么得到这个错误的？ 如果您是自己构建的，是否重新加载了build.psm1？

我在社区中看到很多使用豪华的东西

例如https://github.com/dahlbyk/posh-git 。

pwsh发音posh 。 不幸的是， @ SaschaNaz POSH已作为外壳存在。

我是否错过了@ PowerShell / powershell-committee有关其发音的投票？ :)

我认为也许我们可以将其发音为Microsoft Next Generation Command Line Interface Shell Experience 2017 ，或者只是，您知道powershell 。

在发布Microsoft下一代命令行界面外壳体验2017 Service Pack 2之前，将不会使用它...

不幸的是POSH已经作为外壳存在

是的，当用户想要豪华时，尝试sudo apt install posh然后得到一个完全不同的外壳，这将非常令人困惑。

BTW， poh-sh或pah-sh ？ 肯定是后者吗？

软件包名称仍然是powershell，在此没有更改：

sudo apt install powershell

快速（有意见的）辩论状态帖子：

• 至于binary_的_file名：已经做出并公布了决定： pwsh 。

• 至于_的发音_：

  • 没有人可以将二进制的确切拼写传达给_uninitiated_-别无选择，只能将其拼写出来。

  • 对于_initiated_来说，“ PowerShell”可以说是所有需要的东西，因为从上下文中通常可以很清楚地看到是指二进制文件的_product_还是_file名称（ @markekraus的关注）； 如果是后者，发起人会自动将其翻译为pwsh 。
    如果需要，请添加“ Core”和“ Windows”以消除歧义。

  • 不用说，对确定的非正式单音节绰号的热情追求将继续……
    由于在任何情况下都需要在pwsh上进行心理映射，因此非正式建立的诸如“ Posh”之类的内容也可能会继续使用。

过去，当我们使用MKS Toolkit进行跨平台脚本支持时，我们使用ksh.exe但我们始终将其称为KornShell 。 因此，即使二进制文件是pwsh ，我也将其称为PowerShell。

我认为，如果二进制名称为pwrsh但那条船已经航行，则可以避免整个“您如何发音二进制名称”问题。

回到“过去”（15年前算吗？），我的团队将二进制文件称为“ kish”，“ KornShell”用于shell的一般性讨论。

例：

“输入ooser bin kish，然后按Enter。现在您在KornShell中”

15年前算什么？

这与我猜的人有关。 我与KornShell的合作始于24年前。 15年前，我的女儿还只是个蹒跚学步的孩子，不久前似乎还没有。 Yikes-时间过得真快。

我的团队称二进制为“ kish”

不能说我曾经听过这种发音。 :-)

不能说我曾经听过这种发音。 :-)

是的在该团队之外，它始终是“ ksh”或“ KornShell”。 但这是重点：讨论人们如何发音“ pwsh”（缺少“ PowerShell”），并查看是否存在共识。 这不是一个完全认真的讨论，而且因为它是一个不可发音的单词（所以不要无视团队精神- push ），因此没有任何正式的发音。 但是值得一提的是，也许一个受欢迎的竞争者会胜出，我们将在演示中开始听到它。

在Microsoft工作之前，我曾是Unix人士，并一直称呼ksh Korn Shell和csh C Shell。 我没有回想起当时有人试图将其发音为：P

有人可以简明地解释为什么要进行这样的重大更改吗？ 我跳出循环了（很明显！），并且正在与@powerschill聊天，考虑到符号链接是一回事，我们感到有些惊讶。

我的复习生刚才是否在阅读有关贡献过程的文章。 我认为这首先需要一个RFC，但我可以看到这可能不适用。 接下来，我正在研究有关更改的政策（https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md）。 大家能否评论一下此更改属于哪个存储桶，依此类推？

我不想试图煽动已经解决的事情，我只是想能够与不阅读规格和问题的其他有兴趣的人进行有效的沟通。 谢谢！

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

我的2c。 这是一个重大的突破性变化。 现有生产方案中已有太多的批处理文件，已经使用powershell.exe来启动PowerShell脚本。 我不反对提供额外的简短命令来启动相同的可执行文件，但是删除“ powershell”会造成严重破坏。 请提供一种同时使用两者的方式（别名或其他方式）

@RudolfHenning与以前的Windows PowerShell版本不同，PowerShell Core将与其他版本的Windows PowerShell和旧版本的Windows PowerShell并排运行。 必须有一种从命令行和批处理脚本调用Windows PowerShell和PowerShell核心的方法，而不必调用预期EXE的完整路径，也不必冒着路径顺序冒险的麻烦，而导致powershell.exe调用错误版。

即使在发布PowerShell Core 6.0之后，由于许多官方和社区模块和脚本都需要访问Core中不可用的Full CLR对象，因此仍然需要对许多以Windows为中心的任务使用Windows PowerShell（5.1及更低版本）。

另外，将其脚本从较早版本移植到6.0的任何人都可能需要进行调整，因为5.1和6.0之间有很多重大更改。 由于仍然需要触摸代码，因此可以将批次从powershell.exe切换到pwsh.exe powershell.exe 。 如果他们没有移植PowerShell Core，则不会中断任何操作，并且脚本将继续使用Windows PowerShell以powershell.exe运行。

感谢您的解释。
由于我同时使用Windows和某些Linux操作系统，因此有时需要考虑我的脚本的兼容性-是的，我知道Linux上的PowerShell库严格仍然是Beta。 我已经花了很多时间和精力为Linux机器创建脚本。
无论如何，继续做好工作！

TeamCity的Powershell运行程序假定可执行文件名为powershell 。 由于Linux上没有Powershell 5引起兼容性问题，因此Linux软件包应该继续创建powershell符号链接。 这是不必要的破坏。

什么，我四月到达？ 接下来我们要从PowerShell Commandlet中删除元音吗？ 这一定是个玩笑。

使用“ powershell -command xxxx”的旧脚本（docker）在新的beta-9版本中不再起作用...。

等待暴风雨

我有很多理由要对“最重要”的位置或入口点进行重大更改，但是将命令名缩短6个字节并使其可读性降低并不是其中之一。
过去，我们决定在代码中使用更好/更长的名称的频率，因为阅读可能/必须比写起来容易/。

寄给我2美分
问候
维尔纳

我正在尝试理解愤怒和失败。

人们抱怨说这个新名称令人不寒而栗，但是PowerShell Core仍处于测试阶段。 IMO，如果有人在生产代码中使用Beta版技术，就会招来灾难（我在这里使用礼貌用语）。 alpha和beta版本的本质是充满了重大变化。 没有幻想这不是beta。 beta版本名称6.0.0-beta.9 。

此名称更改对Windows PowerShell无效。 它不应破坏您当前在Windows中执行的任何操作。 如果您在Linux上运行服务器，则需要掌握使用beta版本的事实，而不是将beta版本归咎于beta版本。 如果您无法处理Beta版本之间的重大更改，请考虑使用其他功能，直到稳定版本为RTM。

我知道人们不喜欢这个名字。 您不能总是得到想要的东西。 我个人讨厌PowerShell.exe，因为它很长而且很难输入。 pwsh最少要让我弄乱的字符。 如果您查看讨论线程，可以看到讨论了多个选项，其中一些选项（IMO）比pwsh 。

人们误以为这是与笨拙的Linux小孩融合的尴尬尝试，因为新二进制名称的主要动机之一与Windows有关。 是的，选择了linux-y名称，但是您猜怎么着？ PowerShell现在也是* nix公民。 我认为是时候人们开始习惯这个事实了。 Core的目标之一是跨平台的可移植性。因此，是的，可以并且将要做出的决定不仅限于Windows。

这就是我的2美分。

Core的目标之一是跨平台可移植性

跨平台可移植性的一部分是，如果相同的命令执行相同的操作，则它们应在两个平台上均应工作。 在进行此更改之前，无论我使用什么操作系统，我都可以运行powershell并获得正确的东西。 现在我不能再这样做了。

制作易于使用的软件意味着可以妥善处理一百万个小事情。 使用奇怪和不直观的名称会与此相反。

无论我使用什么操作系统，我都可以运行powershell并获得正确的东西。 现在我不能再这样做了。

不准确。 您可以在Windows上运行powershell并获取Windows PowerShell，然后在Linux上运行powersehll并获取PowerShell Core。 现在，您可以在Windows或Linux上运行pwsh并获取PowerShell Core。 所以现在我们处于您想要的状态。 和以前一样，我们处于不一致状态。

使用奇怪和不直观的名称会与此相反。

很明显，它不是普遍喜欢的，但是...您建议什么选择？ 我看到每个人都对这个名称感到困扰，但没有其他办法可以解决此名称更改所引起的潜在问题。 正如我说的“您不能总是得到想要的东西”

无论选择什么名字，人们都会不高兴。

@markekraus

• 我们知道这是一个测试版-重大更改还可以！
• 我非常喜欢在* nix上制作更好的PS，因为它可以帮助我将（PS）知识从Windows转移到* nix

我的反馈意见涉及可用性，以及关于一场席卷一场的暴风雨的担忧，这次暴风雨再次迫使人们重新命名，并进行了无休止的讨论。

您可以在Windows上运行powershell并获取Windows PowerShell，然后在linux上运行powersehll并获取PowerShell Core。 现在，您可以在Windows或Linux上运行pwsh并获取PowerShell Core。 所以现在我们处于您想要的状态。 和以前一样，我们处于不一致状态。

将Windows和Core分开确实是重命名然后创建“创建更短名称”的更好原因！

我建议对此进行更清晰的沟通（问题标题，发行说明等）
我已经阅读了本期杂志的前2-3页，而讨论仅是关于篇幅...。

其他反馈：
在过去的几周中，我在Docker和* nix上使用PS-Core进行了大量编码
我喜欢，但需要抛光。
想法/建议：
如果名称从Powershell更改为pwsh，为什么不将版本从6.0更改为1.0（相同的讨论，如从“ .Net 5.0”转换为“ dotnet core 1.0”
基本上，CORE更像是1.0版和6版，尤其是在* nix上！

问候
维尔纳

@WernerMairl关于使用1.0而不是6.0.0＃5165进行了公开讨论。 请转到该主题并阅读并发表评论。

另外，由于您一直在使用它，并且遇到了您认为需要完善的内容，因此请检查未解决的问题，看看它们是否可以解决您遇到的问题。 如果有未解决的问题，请对其进行投票或评论，如果没有，请打开一个新问题，以便对其进行修复。 我们中的一些社区成员积极参与解决优先级较低的问题，Microsoft团队在解决优先级较高和难度更大的问题方面做得非常出色。 此外，自己成为贡献者永远不会太晚！

关于问题描述和变更沟通，我同意在此变更的沟通及其必要性上还有改进的余地。 此仓库中不同人员的角色可能会有些混乱，但是我不是PowerShell团队的成员，而只是具有（基本上）论坛管理权限的社区贡献者。 我不能代表PowerShell团队，但我怀疑他们自己也了解这一事实。

在他们的辩护中，这一点很难沟通。 大多数抱怨似乎是由于对Windows PowerShell和PowerShell Core之间的异同缺乏了解。 为了有效地传达这一变化，他们还需要重新整理7月14日博客文章中的内容。 即使到那时，人们仍然难以克服相似性和差异性。 我认为，对于为什么很多人仍然看不到的名称进行更改，需要进行冗长的描述。 我怀疑无论如何火把和干草叉都会来的。

不准确。 您可以在Windows上运行powershell并获取Windows PowerShell，然后在linux上运行powersehll并获取PowerShell Core。 现在，您可以在Windows或Linux上运行pwsh并获取PowerShell Core。 所以现在我们处于您想要的状态。 和以前一样，我们处于不一致状态。

我理解您的意思，但我反驳这不是我想要的。 我的陈述中隐含一个隐藏的假设：只要我使用通用功能，我期望PowerShell和PowerShell Core完全等效。 到目前为止，这在我所有的用例中都没有出现问题。

@sandersaares我相信您的经历会很幸运。 这当然与我的经验不符。 另外，我认为这一假设很危险。 这是一个主要版本，具有大量记录在案的重大更改，而底层平台则完全不同。 这不会像以前的PowerShell主版本那样具有向后100％的向后兼容性。

我看到有些人仍然错误地认为更改可执行文件名称主要是为了节省键入时间。 我可以看到，自从最初用于PR的原始问题开始时，人们对这个印象有何印象？

我同意我们可以改善沟通，因为我们不应该指望每个人都阅读委员会对决定所作的所有评论。 特别是在像这样的有争议的案例上，决策

似乎还对PowerShell Core 6是什么有基本的误解，尤其是与Windows PowerShell有关的误解。 Windows PowerShell 5.1仍将是Windows上的PowerShell的内置版本。 我的团队还将继续根据需要提供支持。 我们完全希望客户在需要的时候会继续依赖Windows PowerShell，至少在未来十年内，它们会非常有用。 我认为直到最近WMF5.1的下载才最终超过WMF4.0的下载。

PowerShell Core 6是PowerShell的下一版本，它不仅跨平台，而且是开源的。 正如@markekraus所指出的，这是一个重大的版本更改，它使我们能够更灵活地接受Windows PowerShell永远不会考虑的重大更改。 还应注意，PowerShell Core 6明确设计为可以并行工作（不仅适用于Windows PowerShell，而且适用于其他版本的PSCore6）。 键入powershell时，在Windows上应该不会出现歧义。 我只在这里指出，6.0与1.0的讨论早在我们公开之前就已经发生了，不太可能重新开放。

@ SteveL-MSFT关于名称更改的博客文章会很好。 它可以用Windows上该问题的清晰示例来介绍名称为何更改的主要驱动程序。 涵盖为什么posh和psh也没有发挥作用也很好。

也许在解压和安装过程中将“ powershell”设置为pwsh的别名。 这只是破坏了我正在工作几天的构建，直到我找到了这个问题。

编辑：在Linux上

@markekraus有一个不错的博客文章，记录了什么和为什么：

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

今天我看到的第一次使用pwsh的SO这里，虽然我怀疑的人知道这个线程...

我们可以得到有关pwsh的发音的官方裁决吗？ PNG规范的第1部分包含一个发音。可以为PowerShell提供一个发音；也可以为PowerShell提供一个发音。 不需要其他SCSI“令人毛骨悚然” /“性感”的情况。

对我来说看起来像“嘘”。

@apjanke通常接受的pwsh发音是posh

为我工作。 感谢您的官方确认！

至于其他的发音： ^[1]

• _Pish Posh！_

• _Poppyposh！_

• _The Shell以前称为PowerShell_（格鲁吉亚语中为_TSFKAP_）

• _不敢说出其名字的Shell（因为其可执行文件的名称是不发音的）_（威尔士语者首选）。

^{[1] [模仿。}