Powershell: Create pwsh as a shorter name for calling powershell.exe

I would like a short alias too, but this is why we didn't get go with posh when we first went out (we talked about it at length). Appears to be still an up-to-date package too.

Open to other suggestions, but most of the obvious *sh ones have been taken. After the only wget/curl alias thing, I'd really like to avoid colliding with other packages out there, even if they're less common.

I'm not too crazy about this whole idea but how about pwsh?

I've never been keen on posh as a shortening of powershell. pwsh seems better but a quick internet search raises some possible issues. if we're going to do this I'd suggest as short as possible so what about just ps?

OK - forget that - I just realised ps is an alias for get-process. that would be too confusing

I'm getting strong deja vu right now. 😉

I appreciate PowerShell's readability (when not using aliases) so running powershell works fine for me.

ps is an existing command on Linux as well.

Some other ideas are: pscmd, psc, monad, psh, pshell

There is definitely diminishing returns with these names though on whether they really save anything or just add unnecessary confusion if they are even available.

CoreSh, pcs, psc

Too bad mosh is taken. psh is taken. [pshell] returns many hits. Interestingly, a search for msh on both Bing and Google bring up many hits for PowerShell (calling it Microsoft Shell), although there exists a msh on Unix (perhaps not used much)

😄 S#, P#

@PowerShell/powershell-committee discussed this and is open to having a shorter symlink name, but we can't squat on anyone that already exists. prsh seems ok.

Wait, wait! I got it: ^sh - or was that **sh? (jk).

prsh seems reasonabe - easier to type than pwsh, for instance, though pwrsh - despite being 1 char. longer - is also worth considering, given that "pwr" is a known abbreviation for "power".

Another, possibly _complementary_ option: provide an _automatic variable_ whose value _invariably_ reflects the very same path of the binary that launched the current session.

bash has $BASH for that.

The advantage of this approach is that it is impervious to variations in / manipulations of $env:PATH.

We already have $PSHOME - arguably, something like $PS is not too much of a stretch.

That said, this relates to the discussion about not polluting the global namespace with automatic variables - see #4216.

.Net Core, CoreFX, CoreCLR, PowerShell Core - we could consider "core" as base.

pscore seems fine to me even if it doesn't end with sh although other Committee members vetoed it

pscore or coreps - LGTM.

We can remember monad and msh (mentioned above).

I like pwrsh the best so far. pscore is not bad either although it's getting kind of longish at 6 chars. Four or less chars is probably ideal but I could live with the 5 chars required by pwrsh.

My concern about incorporating the word "core" is that it carries no useful information on Unix platforms, where there's no other edition that it needs to be distinguished from.

@rkeithhill how about pscx, ha! PowerShell Core Experience. Though, that did make me think of another, pscsh, PowerShell Core Shell.

I'm torn on some of the same names myself. I like the readability of pwrsh and pscore but I agree that 5 characters is the limit. 5 characters covers the first word power and any more than that you might as well type the full thing. monad is a great easter egg and readable, but confusing to those that don't know PowerShell's background. The 4 character prsh works well too.

It would be good to come up with a final list of names that can be used and do an official poll like the Edge team did. If there are any upcoming PS Community or official events, links to the poll can be given out to try and reach a larger audience.

@dragonwolf83:

pscsh is dangerously close to csh - an association we should avoid.

Again, I see no benefit in including the word "core", especially if there's a chance that the editions might be unified one day (and on _Windows_, folks seem to have lived comfortably without a short name for _Windows PowerShell_ for a good decade).

Agreed re obscurity of monad.

My personal vote is for pwsh, prsh, or pwrsh.

P.S.: In case _Windows PowerShell_ also needs a short name, simply prefixing with w could be the solution, although among my favorites that really only (reasonably) rolls off the keyboard as wprsh, so in the two-edition short-name scenario my vote is for the prsh / wprsh pair.

My concern about incorporating the word "core" is that it carries no useful information on Unix platforms, where there's no other edition that it needs to be distinguished from.

:-) Should we rename .Net Core?

@iSazonov: Should we rename Windows PowerShell "Windows PowerShell .NET Framework [FullCLR]?"

I would vote for psh -- the project you cite as a collision hasn't seen a release in 10 years, and was never in package repos in any case.

@Jaykul:

psh? I dunno - needs more "core", if you ask me.

Kidding aside: excellent point about the status of the project and its absence from package repos.

psh has my vote too (and wpsh for Windows PowerShell).

(Pronounced 'pshaw' and 'whiplash', respectively).

psh has my vote too (and wpsh for Windows PowerShell).
(Pronounced 'pshaw' and 'whiplash', respectively).

Are you sure we can't just use posh on windows, and pronounce them pish posh? 🤡

Pish-tosh! That's too much of a mishmash for the whole mishpocha. 🤡

I would vote for psh -- the project you cite as a collision hasn't seen a release in 10 years, and was never in package repos in any case.

No copywrite problem?

No copyright problems?

I hope someone who truly _knows_ will weigh in, but my _guess_ is that this won't be a concern for 2 reasons:

• psh is not the official product name, only an initialism (more loosely speaking, acronym) that is merely a technical aid (though in popular usage it may eventually become a common shorthand for the full product name; it _is_ possible to trademark initialisms/acronyms).

• trademark issues are often about the likelihood of _confusion_ with existing trademarks, and from what we've seen here, at least in the software space there seem to be no collisions (I don't think the creator of the virtually defunct existing psh repo will mind or even has a legal case).

In case someone wants to experiment / needs an interim solution:

Here's an all-aliases solution that defines aliases both inside and outside of PowerShell, on all supported platforms: psh for PS Core, and wpsh for Windows PowerShell.

• Run the following ONCE to set up aliases OUTSIDE of PowerShell (for cmd.exe on Windows, for bash on 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"
  }
}

• Put the following into your $PROFILE to define the same aliases inside of PowerShell - works in both PS Core and 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 @htArgs
        } 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 @htArgs
      }
      # 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"
  }

What about Paua? This is a reference to the beautiful paua shell (a sea shell from New Zealand). Otherwise I think psh is good as well.

You sell seashells from the (New) Zealand Shore? (Just kidding. Beautiful indeed.)

Disclaimer: the following is only of interest to [hobby] linguists.

Phonetically, paua only works for non-rhotic dialects of English (e.g., UK, NZ, Australia).

And Bostonians.

@PowerShell/powershell-committee should close on this for beta.8

How about Posh6

How about Posh6

Feels like that would go out of date faster than putting a version number in a file extension... ;)

Yes but a shell script that launches it will know what version it's running.

Although I like posh, I think the main concern is that there's an existing package for Linux called Posh so to avoid another curl incident, I think the next best option is pwsh

I like pwsh. Would have been nice to have 10 years ago. I miss msh.

I vote for psh.
gnp/psh hasn't been committed to in nearly 5 years. It may as well be abandonware.

I hate to say it, but this is one of those things where it might be too hard to gather strong consensus. :\

At this point, to close things down, and to avoid any kind of collision (more "good faith" than legal), I'm all in on pwsh.

Let me ask it this way: does anyone have a strong reason not to go with pwsh?

Would anyone have concerns if pwsh is the name of the executable and powershell is the symlink/shortcut?

Before we make any approves here we should answer what is "current" version and how we're going to refer to it and its target version?

@iSazonov not sure I understand your question. This isn't related to powershell -v N if that is what you are asking. This simply allows using pwsh instead of powershell (although we would still support spelling out powershell).

My concern is more about symlinks like powershell -> powershell-6.0.0-beta.7
If say about language we like aliases in interactive session because it give us a comfort environment but the aliases is big headache in scripts. I see the same for powershell short name - it's probably good for speed type but it may be really problem for directory tree (symlinks).

Another thought. Should we think about speed type? Not all proposed cases is good from this perspective.
Last thought is about pronunciation. Interesting, on Russian we use "пош" ("posh") and hypocorism "пошик" ("poshik") since PowerShell birth. I guess that any Russian man will vote for "posh" or "psh".

Just to be clear, pwsh wouldn't be an alias (in PowerShell terms), it should be something you could call from cmd.exe or a batch file as it physically exists. Although it's not clear to me how we actually implement this if we want to support both a short name and powershell without having two executables (although poweshell.exe is relatively quite small...).

As for posh and psh vs pwsh, the primary concern with posh and psh is that they already exist (regardless how prominent they are). We had a problem early on with our curl alias as it conflicted with an existing native tool and (perhaps we're overly cautious here) we're trying to avoid a similar situation with the short hand which is why we're leaning towards pwsh. Perhaps if I type pwsh often enough people will get used to it :)

Other side. How we resolve the same in PowerShell? We suggest users aliases and IntelliSense to seed up typing.
When we discussed aliases in one of the discussions here, we said that all the current alias should do not readonly - we should allow users to remove/change any aliases . In other words, aliases should not be exclusively standard. Only basic cmdlet names must be standard. From this point of view, we should not offer a "standard" alias for "powershell" - any community or distributive should be able to choose the name they like and which corresponds to their spirit, also they could offer IntelliSense too.

@SteveL-MSFT - I think that 'pwsh' will probably stick with people just fine.

That being said, you folks mentioned curl incident as a reason not use 'psh'. I find that problematic as you are simply boxing yourself (us) to a corner by drawing parallels too far!

'curl' is one of the most used tools in linux world. It is wise to be overly cautious not to repeat 'curl' snafu for 'living' / 'active' software but why should this courtesy be extended to abandonware?

Let the curl incident teach us a lesson, just not the wrong one.

In support of @AdilHindistan's advice, let me reiterate @Jaykul's to-the-point analysis (the thread's gotten long, it's hard to keep track):

I would vote for psh -- the project you cite as a collision hasn't seen a release in 10 years, and was never in package repos in any case.

In other words: The fact that psh was seemingly never part of (major) package repositories (I've only checked apt (Ubuntu, Debian) and yum (Fedora, RedHat)) - i.e., was always a _niche product_ - _and_ that it can for all intents and purposes be considered abandoned after 10+ years of inactivity makes it a perfect candidate.

(By contrast, the fact that posh is still an available package via apt, irrespective of its maintenance status, disqualifies it, in my opinion.)

I would agree with the points made that psh is a viable option and should be considered

As for how to _implement_ the short name as a symlink / stub, assuming the name of the actual executable will remain powershell[.exe]:

Let's assume that the short name will be, say, psh (just to pick one of the names discussed, at random).

Unix platforms

The installer will _additionally_ have to do the equivalent of the following:

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

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

In other words: create an additional symlink named psh that simply points to the existing powershell symlink.

On macOS, this would result in symlink chain such as the following:

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

Any calling shell, including PS Core itself, would therefore be able to use psh as a shorter alternative to powershell.

Windows

On Windows, things are more complicated:

• at least as of beta.7, from _outside_ of PS _Core_, it is only _Windows_ PowerShell that is in the PATH.
• There should be distinct shorthands for Windows PowerShell vs. Powershell Core for targeted invocation: psh for PS Core and wpsh for Windows PS (this name should be fine too, because it is also not in use in the apt and yum repos).

Windows PS

_Windows_ PS could define symlinks - one each in $env:SystemRoot\System32\PowerShell\v1.0 (64-bit) and $env:SystemRoot\SysWOW64\PowerShell\v1.0 (32-bit) as follows:

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

By virtue of $PSHOME being in the $PATH, any shell, including PS Core and Windows PS itself, could then invoke Window PS as wpsh.

PS Core

The shorthand file by itself could be placed in a directory that is in the PATH by default, which would allow invocation even without PS Core's $PSHOME itself being in the PATH.

64-bit-vs.-32-bit considerations don't apply (PS Core is 64-bit only), so $env:SystemRoot (typically, C:\Windows) could be chosen.

Unfortunately, use of _symbolic links_ is at least currently _not_ an option, because PowerShell Core refuses to run when invoked via a symlink that has a different name:

From an _elevated_ PS session:

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

Invoking psh.exe fails as follows:

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.

If anyone knows of a way around this, do let us know.

(Curiously, if you define the symlink _without extension_ - psh instead of psh.exe - invocation succeeds in principle, but no parameters are passed through.)

A workaround is to use a stub batch file (again, run from an _elevated_ PowerShell session):

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

Any calling shell, including Windows PowerShell and PS Core itself, can then use psh as a shorthand for invoking PS Core.

@mklement0 I was thinking the same thing in terms of using a symlink on Linux/macOS and a batch file for Windows (and I wouldn't do anything for Windows PowerShell as that would just stay as powershell).

It seems the most obvious thing is that powershell is the primary and psh is the link, but I was thinking perhaps we should flip that around so that psh is the name of the exe and powershell is the link. The reasoning is that with a new audience on non-Windows and to differentiate from Windows PowerShell, it seems that the preference is that people use psh to refer to PowerShell Core and powershell is just provided for app-compat (perhaps muscle memory for some people as they transition). However, I know not everyone is sold on this idea.

If we'll see that psh very popular we can swap powershell and psh.

For adding alias may be help https://stackoverflow.com/questions/2016722/one-dll-multiple-projects

Don't like the idea of psh becoming the exe and PowerShell being relegated to being a link. You're throwing away 10 years of audience loyalty for potential ease of use on non-Windows where the audience size is unknown and (at least to begin with) potentially small.

The more I see of PowerShell v6 the more it seems the existing Windows users are being ignored in an attempt to convince non-Windows users to adopt PowerShell. Where does this process end?

@RichardSiddaway I don't get the impression that the PowerShell team is ignoring Windows users at all and I am primarily a Windows user with a Windows Phone. I was the one that requested this not out of some Linux concept, but from my own challenges of moving away from cmd to powershell.

The fact is, Windows PowerShell is a mature product but not built with cross-platform in mind. To make this work, the initial investment has to be higher towards to cross-platform in the beginning which will benefit both worlds. Things will even out over the next few releases.

Other than aliases and parameter aliases, I don't see a lot that negatively impacts Windows users. If there is a specific issue that is a concern, then please raise it in those issues. Debate is good for the platform and we do need to make sure nothing special about PowerShell gets lost in the transition.

@SteveL-MSFT can you provide some more of your reasoning for making psh or pwsh becomes the .exe? If there benefits that are gained from it, I may be more inclined to favor it.

Ouch on the batch file. Anyway to make the symlink work on Windows? I rather have that than another layer through cmd.

@dragonwolf83 I would imagine over time, people would prefer typing 3 or 4 characters vs 10, so although we will always supporting typing out powershell, it seems like from a long term perspective, we should optimize for the shorter version

You comments about Windows PowerShell are spot on.

@dragonwolf83:

Ouch on the batch file. Any way to make the symlink work on Windows?

I hear you. Alas, my cry for help has received very little attention so far.

powershell.exe is 78k, would it be so bad to have another 78k as psh.exe...

Having 2 duplicate executables might be an easy solution but could also lead to confusion since I can imagine that users will start pondering whether there is a difference between the 2. If I were new to PowerShell and saw 2 different examples (e.g. on SO) that show how to call/open PowerShell then I would immediately start to wonder which example I should choose because I would assume that there is a difference...

IMO this is silly. cmd.exe is largely hidden in Windows 10 1703, so you would seldom launch powershell.exe from the legacy shell.

Not a big fan of this - how often are you typing powershell that it becomes a problem? (Also, total bikeshed issue ;) ) In Windows 10 and Server 2016, set "Replace command prompt with Windows PowerShell when I right click the start menu or press Win+X" and it's as short as Win+x, i or in Linux, add an alias to your existing shell with the name you prefer.

That said, what about:

• ps1 - after the file extension on Windows, short, easy to type, memorable
• psps - is short and typeable, but leaves itself open to 'typical M$ bloat' slanging
• ips - as if for Invoke-PowerShell, it doesn't appear to be a package in RedHat or Ubuntu repos and yum provides "*/ips" shows no binaries to clash with in a quick check

Let me ask it this way: does anyone have a strong reason not to go with pwsh?

It's ugly and unpronounceable, takes more syllables to say than 'powershell' itself, isn't particularly easy to type, and looks like it derives from internet-speak pwnd/pwnt.

If we're soon to have PowerShell as the default shell on Windows, the file name (lenght) becomes unimportant.

PowerShell Core is portable project - we have to think about Unix, too.

@PowerShell/powershell-committee discussed this and where we landed is to have PSCore6 binary called just pwsh without an additional shortcut/alias for powershell. The benefit is making it explicit without ambiguity on Windows whether you are using Windows PowerShell or PowerShell Core. On non-Windows, it's shorter to type and more consistent with other shell naming. Based on customer feedback, we can always add a powershell link/shortcut/alias in the future.

My vote is psh.exe.

@jandrusk The PR already got merged yesterday, so it will be pwsh.exe. Jeffrey has already tweeted about this here.

Long live the new PassWord / Per-Week / PoliceWoman SHell!

My vote would have been to leave it alone.

So how are we pronouncing pwsh?

p.w.s.h
p.wush
p.woosh
puh.wush

Hopefully something better than those

@jonathanmedd I've been using pwish like wish with a p.

Given that _pwsh_ is a recursive acronym (similar to _GNU_) - Please, Why pwSH? - I suggest "pweesh", like a cute bunny with a lisp saying "please".

Kidding aside:

• While I personally think settling on pwsh was unfortunate, I assume that we'll get used to it soon and won't think about it again.

• As for pronunciation: I personally don't see the need for one, given that the full name is short enough, and to anyone living in the world of PowerShell the mapping will be obvious. (An example from the Unix world: zsh is apparently pronounced zee shell or zed shell, not as a single syllable).

P-Dub Shell?

P Double U Shell or P Double U S H is just painful to say. More syllables than PowerShell but you'd probably want to distinguish PowerShell from pwsh. Just as bash is distinguished from Bourne-Again Shell.

you'd probably want to distinguish PowerShell from pwsh

In terms of the official full names, it's _PowerShell Core_ vs. _Windows PowerShell_ - _PowerShell_ by itself can refer to any edition.
If it's not clear from the context, adding the appropriate qualifier will disambiguate - and perhaps won't be needed all that often (e.g., in a pure Unix context).

Longer-term, given that PowerShell Core is the edition that runs on "all" platforms, I wouldn't be surprised if _PowerShell_ became a common, informal shorthand for _PowerShell Core_ (the "default" PowerShell), with a qualifier - _Windows_ - only used to refer to the Windows edition.

As an aside:

Just as bash is distinguished from Bourne-Again Shell.

bash _is_ the _Bourne-Again SHell_ - it contrasts with its predecessor, the _Bourne SHell_ (sh,
before POSIX standardized the language).

@mklement0 I'm talking about distinguishing pwsh the binary from PowerShell the language/shell. Not distinguishing different implementations/platforms of PowerShell. Just as bash is used to distinguish the binary from Bourn-Again SHell. They are interchangeable, yes, but when you need to distinguish the 2 you need a clear way to pronounce pwsh.

push :smile:

So maybe:

p shell or p w shell

@markekraus:

Ah, I see, thanks for clarifying.

If you want to convey the _exact_ name of the binary, no pronunciation short of _spelling out_ the name will help you (that would only have worked with something like posh).

Thus, referring to the _PowerShell binary/executable_ should work for all those already in the know, and for others you'll have to spell it out anyway.

If you want to convey the exact name of the binary, no pronunciation short of spelling out the name will help you.

We will have to agree to disagree on that one 😃.

I understand your _desire_ for that to work - as it does with "bash" and "posh", for instance - but as your own struggles above attest, it doesn't work with "pwsh" - which, it's fair to assume, we're stuck with now.

it doesn't work with "pwsh"

well, not with that attitude it doesn't! 😉 I have been calling it pwish and probably will continue to do so. But I'm just creating a dialogue to see if other come up with something else. push is a good one considering the w pronunciation in some languages. pwsh not completely irredeemable, IMO. maybe everyone will settle on p w s h. but it's too early to say "we're done here" and consider the matter decided, IMO.

:)

You're right.

I guess I was focusing too much on the aspect of conveying the _exact spelling_ to someone not yet familiar with PowerShell rather than a short name established _by convention_ for those already in the know (who already know how to map that short name to pwsh).

What about MSPosh. Shorter than PowerShell.exe and follows standards, while also doubling as a fun name for The PowerShell Hero?

@1RedOne the PowerShell hero/avatar will always be PoSH-Chan in my ❤️

It seems PWSH team was rushing to change its name. :-)

I vote for pscmd.exe

when typing cmd in windows, it should actually come up! and it's actually replacing the cmd...

if this is a question of muscle memory, let's fix that problem..

if it's just for fun to find it a cool new name, then it should be pscore.exe, since that's what it is.

just my 2 cents.

pwsh, the wwrld's fwremwst Wbject-Wriented shell. I'm lwwking fwrward tw new cmdlets continuing this pattern:

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

;)

--

Ref pronunciation, what about "powsh" said like "pouch" or "couch" with a soft "s". (Think Sean Connery impressionists saying 'pouch').

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.

I'm guessing this error message is related to this issue. How do I fix this?

As far as the actual name issue goes, I vote for pwsh, since Bash is the Bourne Again SHell.

I vote for PWSH. And I'd pronounce it as push.
I've seen lots in the community using posh though, so that would be my second choice, though I think MS may be trying to get away from calling it posh.

I vote for pwr!

@DaleMitchell how did you get that error? If you built it yourself, did you reload build.psm1?

I've seen lots in the community using posh though

https://github.com/dahlbyk/posh-git for example.

pwsh is pronounced posh. @SaschaNaz POSH already exists as a shell unfortunately

Did I miss a @PowerShell/powershell-committee vote on how it's pronounced? :)

I thought maybe we could pronounce it Microsoft Next Generation Command Line Interface Shell Experience 2017, or maybe just, you know, powershell.

Won’t use it until Microsoft Next Generation Command Line Interface Shell Experience 2017 Service Pack 2 is released...

POSH already exists as a shell unfortunately

Yeah, it will be VERY confusing when a user wants posh, tries sudo apt install posh and then gets a completely different shell.

BTW, poh-sh or pah-sh? Most certainly the latter?

The package name is still powershell, no change there:

sudo apt install powershell

A quick (opinionated) state-of-the-debate post:

• As for the _file name of the binary_: the decision has been made and publicized: pwsh it is.

• As for _pronunciation_:

  • There is none that can convey the exact spelling of the binary to the _uninitiated_ - no choice but to spell it out.

  • To the _initiated_, "PowerShell" is arguably all that's needed, as it will usually be clear from the context whether one is referring to the _product_ or the _file name of the binary_ (@markekraus's concern); if the latter, the initiated will automatically translate that to pwsh in their heads.
    Add "Core" and "Windows" to disambiguate, if needed.

  • Needless to say, the impassioned quest for the definitive informal one-syllable moniker will continue...
    Since an act of mental mapping onto pwsh is required in any event, informally established ones such as "Posh" may as well see continued use.

Back in the old days when we used MKS Toolkit for cross-platform script support, we used ksh.exe but we always called it KornShell. So even though the binary is pwsh, I will call it PowerShell.

I think this whole "how do you pronounce the binary name" issue could have been avoided if the binary name had been pwrsh but that ship has sailed.

Back in the "old days" (does 15 years ago count?) my team called the binary "kish", and "KornShell" was for general discussion of the shell.

Example:

"Type ooser bin kish then hit enter. Now you are in the KornShell"

does 15 years ago count?

It's somewhat relative to the person I guess. My experience w/KornShell started 24 years ago. 15 years ago my daughter was a toddler and that doesn't seem that long ago. Yikes - time flies.

my team called the binary "kish"

Can't say I've ever heard it pronounced that way. :-)

Can't say I've ever heard it pronounced that way. :-)

Yea. outside of that team it has always been "ksh" or "KornShell". But that's kind of the point: discussing how people will pronounce the letters "pwsh" (absent "PowerShell") and seeing if there is any consensus. It's not a completely serious discussion and nothing is ever going to be an official pronunciation since its an unpronounceable word (no disrespect intended to team-push). but it has merit that maybe a popular contender will win out and we will start hearing it in presentations.

Before working at Microsoft, I was a Unix person and has always called ksh Korn Shell and csh C Shell. I don't recall anyone back in those days trying to pronounce them as words :P

Could someone concisely explain why a breaking change like this was made? I'm out of the loop (clearly!), and was chatting with @powerschill, and we are just somewhat surprised, given that symlinks are a thing.

Did my refresher reading on the contributing process just now. I thought this would require an RFC at first, but I can see how this may not apply. Next, I'm looking at the policy on breaking changes (https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md). Can y'all comment on which bucket this change fell into, and so on?

Not trying to stir up something that's clearly settled, I just want to be able to communicate effectively to others interested who don't go reading specs and issues. Thanks!

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

my 2c. This is a major breaking change. Too many existing batch files in exiting production scenarios already uses powershell.exe to initiate PowerShell scripts. I'm not against providing an additional short command to launch the same executable but removing 'powershell' will cause major havoc. Please provide a way to use both (alias or whatever)

@RudolfHenning Unlike previous versions of Windows PowerShell, PowerShell Core will operate side-by-side with other version of itself and older versions of Windows PowerShell. There needs to be a way to call both Windows PowerShell and PowerShell core from the command line and from batch scripts without having to call the full path of the intended EXE or without risking the path order resulting in powershell.exe calling the wrong version.

Even after PowerShell Core 6.0 is released, there will continue to be a need to use Windows PowerShell (5.1 and lower) for many Windows-centric tasks as many of the official and community modules and scripts require access to Full CLR objects unavailable in Core.

Also, anyone porting their scripts from earlier versions to 6.0 will likely need to make adjustments as there are quite a lot of breaking changes between 5.1 and 6.0. Since the code will need to be touched anyway, the batch can be switched to pwsh.exe from powershell.exe. If they are not porting PowerShell Core, then nothing will break and the scripts will continue to run with powershell.exe using Windows PowerShell.

Thanks for the explanation.
Since I'm using both Windows and some Linux OS'es the compatibility of my scripts is a concern at times - yes I know the PowerShell libraries on Linux are strictly still Beta. I've invested quite some time and effort in creating scripts for my Linux machines.
Anyway, keep on doing the good work!

TeamCity's Powershell runner assumes that the executable is called powershell. Since there is no Powershell 5 on Linux to cause compatibility problems, the Linux package should have continued to create the powershell symlink. This was unnecessary breakage.

What the, did I arrive in April? Are we going to remove vowels from PowerShell commandlets next? This must be a joke.

older scripts (docker) using "powershell -command xxxx" not working anymore with the new beta-9 release....

waiting for the shitstorm

There my be a lot of reasons to to a breaking change on the "most important" place or entry point, but shortening the command name by 6 bytes and make it less readable is not one of them....
how often in the past we decide to use a better/longer name inside our code because reading can/must be easier then writing ....

cust my 2cent
regards
Werner

I'm trying to understand the outrage and failing.

People are complaining that the new name is breaking things, but, PowerShell Core is still in beta. IMO, if someone is using a beta tech in production code they are inviting disaster (I'm using polite language here). The nature of alpha and beta releases is that of being filled with breaking changes. There is no illusion that this is not beta. beta is baked into the version name: 6.0.0-beta.9.

This name change has no effect on Windows PowerShell. It should not be breaking anything you are currently doing in Windows. If you are doing things in Linux, then you need to own up to the fact that you are using a beta version, instead of blaming the beta version for being a beta version. Consider using something else until the stable release is RTM if you cannot handle the breaking changes between beta releases.

I get that people don't like the name. You can't always get what you want. I personally have hated PowerShell.exe because it is long and awkward to type. pwsh is at least less characters for me to mess up. If you look at the discussion thread you can see that multiple options were discussed some of them way worse (IMO) than pwsh.

People misunderstand this as some awkward attempt to blend in with the cool Linux kids, when one of the primary motivators for a new binary name is Windows related. Yes, a linux-y name was chosen, but guess what? PowerShell is now a *nix citizen too. I think it's time people get used to that fact. One of the goals of Core is cross-platform portability, So yes, decisions can and will be made with more than Windows in mind.

so that's my 2 cents worth.

One of the goals of Core is cross-platform portability

One part of cross-platform portability is that the same commands should work on both platforms if they do the same thing. Before this change, I could run powershell no matter what OS I was using and get the right thing. Now I can no longer do that.

Making software that is easy to use means caring properly for a million little things. Using strange and unintuitive names works counter to that.

I could run powershell no matter what OS I was using and get the right thing. Now I can no longer do that.

Not accurate. You could run powershell on windows and get Windows PowerShell then run powersehll on linux and get PowerShell Core. Now you can run pwsh on windows or linux and get PowerShell Core. So NOW we are in the state you desire. where as before we were in an inconsistent state.

Using strange and unintuitive names works counter to that.

well its clear it's not universally liked, but... what alternative do you suggest? I see everyone griping about the name but no alternatives to the underlying problem this name change addresses. As I said "You can't always get what you want"

No matter what name was chosen, people would be unhappy.

@markekraus

• we know that is is a beta - breaking changes are ok!
• i'm a big fan of making better PS on *nix because it helps me to transfer my (PS) knowledge from Windows to *nix

My feedback was about usability and the concern of a shitstorm that enforces some re-names again and endless discussions.

You could run powershell on windows and get Windows PowerShell then run powersehll on linux and get PowerShell Core. Now you can run pwsh on windows or linux and get PowerShell Core. So NOW we are in the state you desire. where as before we were in an inconsistent state.

Separating Windows and Core is really a BETTER reason for the rename then "Create a shorter name" !

I suggest to do more clear communications about that (Issue Title, Release Notes etc)
I have read the first 2-3 pages of this issue and the discussion was only about length....

other feedback:
In the last weeks i have done a lot of codings with PS-Core on Docker and *nix
I like it but needs some polishing.
Idea/Suggestion:
if the name is changed from Powershell to pwsh, why not changing the Version from 6.0 to 1.0 (same discussion like the transform from ".Net 5.0" to "dotnet core 1.0
Basically CORE is more like a version 1.0 the a version 6, specially on *nix!!

regards
Werner

@WernerMairl There is an open discussion about using 1.0 instead of 6.0.0 #5165. Please go to that thread and read and comment.

Also, since you have been using it and have run into things you think need polishing, please check open issues to see if they address what you have run into. If there is an open issue, vote on it or comment and if not please open a new issue so they can be fixed. Several of us community members are actively engaged in fixing the lower priority issues and the Microsoft Team has been doing an amazing job working the higher priority and more difficult issues. Also, it's never too late to become a contributor yourself!

On the issue description and change communication, I agree that there was room for improvement on the communication of this change and why it was necessary. The roles of different people in this repo can be a bit confusing, but I am not a part of the PowerShell team, just a community contributor with (essentially) forum moderation privileges. I can't speak for the PowerShell Team, but I suspect they understand this fact themselves.

In their defense, this one is kind of hard to communicate. The majority of complaints seem to stem from the lack of understanding of the similarities and differences between Windows PowerShell and PowerShell Core. In order to effectively communicate this change, they would have needed to also rehash what was spelled out in the July 14th blog article. Which even then, people are still having difficulty navigating the similarity and differences. I think that it would need a lengthy description as to why the name change was done that many would still not read. I suspect the torches and pitchforks would have come no matter what.

Not accurate. You could run powershell on windows and get Windows PowerShell then run powersehll on linux and get PowerShell Core. Now you can run pwsh on windows or linux and get PowerShell Core. So NOW we are in the state you desire. where as before we were in an inconsistent state.

I understand what you mean but I counter that this is not what I want. There is a hidden assumption implicit in my statement: I expect PowerShell and PowerShell Core to be completely equivalent as long as I use common features. So far, this has gone without issues in all my use cases.

@sandersaares I believe your experience to be one of luck. It certainly doesn't match my experience. Also, I believe that assumption to be dangerous. This is a major version with a ton of documented breaking changes with a completely different underlying platform. This wont be like previous major versions of PowerShell with near 100% backwards compatibility.

I see some people still making the false assumption that the changing of the executable name was primarily to save on typing. I can see how people may have gotten this impression since this original issue that was used for the PR started with a title asking for a shorter name.

I agree that we can improve our communication as we shouldn't expect everyone to read all the comments that the Committee makes on decisions. Particularly on a controversial one like this where the summary of the decision is easily lost.

It also seems that there is a fundamental misunderstanding of what PowerShell Core 6 is, particularly in relation to Windows PowerShell. Windows PowerShell 5.1 is still and will be the in-box version of PowerShell on Windows. My team also continues to support it as needed. We fully expect customers to continue to rely on Windows PowerShell for as long as they need to which may very well be at least the next 10 years. I think it was only recently when the downloads of WMF5.1 finally surpassed the downloads of WMF4.0.

PowerShell Core 6 is the next evolution of PowerShell where it is not only cross platform but also Open Source. As @markekraus noted, it is a major version change which allowed us more flexibility on accepting breaking changes we would never consider for Windows PowerShell. Also noted that PowerShell Core 6 is explicitly designed to work side-by-side (not only with Windows PowerShell but other versions of PSCore6). There should be no ambiguity of what you get on Windows when you type powershell. I'll just note here that the 6.0 vs 1.0 discussion already happened a long time back before we went public and is unlikely going to be reopened.

@SteveL-MSFT a blog post on the name change would be good. It could cover the main driver for why the name change with a clear example of the problem on Windows. It would also be good to cover why posh and psh didn't make the cut as well.

Maybe set up "powershell" as an alias for pwsh during unpacking+install. This just broke a build I was working on for a couple of days until I tracked down this issue.

Edit: on linux

@markekraus has a nice blog post that captures the what and whys:

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

Today I saw the first usage of pwsh on SO here although I doubt that the person knows about this thread...

Can we get an official ruling on the pronunciation of pwsh? The PNG spec includes a pronunciation in its Section 1. May as well provide one for PowerShell; don't want another SCSI "scuzzy"/"sexy" situation.

Looks like "poosh" to me.

@apjanke the generally accepted pronunciation of pwsh is posh

Works for me. Thanks for the official confirmation!

As for alternative pronunciations:^[1]

• _Pish Posh!_

• _Poppyposh!_

• _The Shell Formerly Known as PowerShell_ (_TSFKAP_ in Georgian)

• _The Shell That Dare Not Speak Its Name (Because the Name of Its Executable is Unpronounceable)_ (preferred by Welsh speakers).

^{[1] [Parody. Not to be taken seriously.](https://en.wikipedia.org/wiki/Poe%27s_law)}