New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create pwsh as a shorter name for calling powershell.exe #4214

Closed
dragonwolf83 opened this Issue Jul 11, 2017 · 123 comments

Comments

@dragonwolf83

dragonwolf83 commented Jul 11, 2017

The muscle memory from switching cmd to powershell is a pain. It is made worse by the fact that it is much longer than typing out cmd or bash. Even with Windows Search in Start, it often picks up the ISE if you have been using it awhile, so typing out the full name is often needed.

A better name would be posh.exe or other valid extension. It is as long as bash and just one character longer than cmd. Posh has been the accepted abbreviation in the community for all things PowerShell so there is some familiarity there. I don't believe there are any conflicts with other apps that this would cause, but that would need some digging.

This could be achieved in two ways.

  1. Create a an official shortcut or symbolic link named posh that would reference powershell.exe
  2. Rename powershell.exe to posh.exe.

The former maintains backwards compatibility and allows the user to choose between posh or powershell.exe. Existing scripts not impacted.

The latter could help give more freedom to issues like #4199 and other POSIX proposals to how the shell is started. However, it is a breaking change and would need to be reviewed for the impact and the branding implication.

I think making an official posh shortcut is the best option with minimal impact. New documentation could give preference to posh as the way to enter PowerShell.

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Jul 19, 2017

Member

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.

Member

joeyaiello commented Jul 19, 2017

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.

@rkeithhill

This comment has been minimized.

Show comment
Hide comment
@rkeithhill

rkeithhill Jul 19, 2017

Contributor

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

Contributor

rkeithhill commented Jul 19, 2017

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

@RichardSiddaway

This comment has been minimized.

Show comment
Hide comment
@RichardSiddaway

RichardSiddaway Jul 19, 2017

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?

RichardSiddaway commented Jul 19, 2017

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?

@RichardSiddaway

This comment has been minimized.

Show comment
Hide comment
@RichardSiddaway

RichardSiddaway Jul 19, 2017

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

RichardSiddaway commented Jul 19, 2017

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

@joeyaiello

This comment has been minimized.

Show comment
Hide comment
@joeyaiello

joeyaiello Jul 19, 2017

Member

I'm getting strong deja vu right now. 😉

Member

joeyaiello commented Jul 19, 2017

I'm getting strong deja vu right now. 😉

@rkeithhill

This comment has been minimized.

Show comment
Hide comment
@rkeithhill

rkeithhill Jul 19, 2017

Contributor

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

Contributor

rkeithhill commented Jul 19, 2017

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

@dragonwolf83

This comment has been minimized.

Show comment
Hide comment
@dragonwolf83

dragonwolf83 Jul 19, 2017

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.

dragonwolf83 commented Jul 19, 2017

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.

@iSazonov

This comment has been minimized.

Show comment
Hide comment
@iSazonov

iSazonov Jul 19, 2017

Collaborator

CoreSh, pcs, psc

Collaborator

iSazonov commented Jul 19, 2017

CoreSh, pcs, psc

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Jul 20, 2017

Member

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)

Member

SteveL-MSFT commented Jul 20, 2017

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)

@iSazonov

This comment has been minimized.

Show comment
Hide comment
@iSazonov

iSazonov Jul 21, 2017

Collaborator

😄 S#, P#

Collaborator

iSazonov commented Jul 21, 2017

😄 S#, P#

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Jul 26, 2017

Member

@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.

Member

SteveL-MSFT commented Jul 26, 2017

@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.

@mklement0

This comment has been minimized.

Show comment
Hide comment
@mklement0

mklement0 Jul 28, 2017

Contributor

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.

Contributor

mklement0 commented Jul 28, 2017

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.

@iSazonov

This comment has been minimized.

Show comment
Hide comment
@iSazonov

iSazonov Jul 30, 2017

Collaborator

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

Collaborator

iSazonov commented Jul 30, 2017

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

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Jul 30, 2017

Member

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

Member

SteveL-MSFT commented Jul 30, 2017

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

@iSazonov

This comment has been minimized.

Show comment
Hide comment
@iSazonov

iSazonov Jul 30, 2017

Collaborator

pscore or coreps - LGTM.

We can remember monad and msh (mentioned above).

Collaborator

iSazonov commented Jul 30, 2017

pscore or coreps - LGTM.

We can remember monad and msh (mentioned above).

@rkeithhill

This comment has been minimized.

Show comment
Hide comment
@rkeithhill

rkeithhill Jul 30, 2017

Contributor

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.

Contributor

rkeithhill commented Jul 30, 2017

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.

@mklement0

This comment has been minimized.

Show comment
Hide comment
@mklement0

mklement0 Jul 30, 2017

Contributor

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.

Contributor

mklement0 commented Jul 30, 2017

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.

@dragonwolf83

This comment has been minimized.

Show comment
Hide comment
@dragonwolf83

dragonwolf83 Jul 30, 2017

@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 commented Jul 30, 2017

@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.

@mklement0

This comment has been minimized.

Show comment
Hide comment
@mklement0

mklement0 Jul 30, 2017

Contributor

@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.

Contributor

mklement0 commented Jul 30, 2017

@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.

@mklement0

This comment has been minimized.

Show comment
Hide comment
@mklement0

mklement0 Jul 30, 2017

Contributor

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.

Contributor

mklement0 commented Jul 30, 2017

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.

@SteveL-MSFT SteveL-MSFT added this to the 6.0.0-HighPriority milestone Jul 30, 2017

@iSazonov

This comment has been minimized.

Show comment
Hide comment
@iSazonov

iSazonov Jul 31, 2017

Collaborator

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?

Collaborator

iSazonov commented Jul 31, 2017

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?

@mklement0

This comment has been minimized.

Show comment
Hide comment
@mklement0

mklement0 Jul 31, 2017

Contributor

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

Contributor

mklement0 commented Jul 31, 2017

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

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 22, 2017

Collaborator

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.

Collaborator

markekraus commented Oct 22, 2017

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.

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Oct 22, 2017

Member

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

Member

SteveL-MSFT commented Oct 22, 2017

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

lisaoakley added a commit to cloudfoundry-incubator/greenhouse-ci that referenced this issue Oct 25, 2017

[azure] Update powershell executable name
It's been renamed to [pwsh](PowerShell/PowerShell#4214)

[#150612728]

Signed-off-by: Lisa Oakley <loakley@pivotal.io>
@halr9000

This comment has been minimized.

Show comment
Hide comment
@halr9000

halr9000 Oct 25, 2017

Contributor

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!

Contributor

halr9000 commented Oct 25, 2017

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!

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT
Member

SteveL-MSFT commented Oct 25, 2017

@RudolfHenning

This comment has been minimized.

Show comment
Hide comment
@RudolfHenning

RudolfHenning Oct 26, 2017

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 commented Oct 26, 2017

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)

@iSazonov iSazonov referenced this issue Oct 26, 2017

Closed

why pwsh #5241

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 26, 2017

Collaborator

@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.

Collaborator

markekraus commented Oct 26, 2017

@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.

@RudolfHenning

This comment has been minimized.

Show comment
Hide comment
@RudolfHenning

RudolfHenning Oct 26, 2017

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!

RudolfHenning commented Oct 26, 2017

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!

@doxxx

This comment has been minimized.

Show comment
Hide comment
@doxxx

doxxx Oct 26, 2017

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.

doxxx commented Oct 26, 2017

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.

@sandersaares

This comment has been minimized.

Show comment
Hide comment
@sandersaares

sandersaares Oct 27, 2017

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

sandersaares commented Oct 27, 2017

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

@WernerMairl

This comment has been minimized.

Show comment
Hide comment
@WernerMairl

WernerMairl Oct 27, 2017

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

WernerMairl commented Oct 27, 2017

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

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 27, 2017

Collaborator

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.

Collaborator

markekraus commented Oct 27, 2017

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.

@sandersaares

This comment has been minimized.

Show comment
Hide comment
@sandersaares

sandersaares Oct 27, 2017

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.

sandersaares commented Oct 27, 2017

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.

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 27, 2017

Collaborator

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.

Collaborator

markekraus commented Oct 27, 2017

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.

@WernerMairl

This comment has been minimized.

Show comment
Hide comment
@WernerMairl

WernerMairl Oct 27, 2017

@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 commented Oct 27, 2017

@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

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 27, 2017

Collaborator

@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.

Collaborator

markekraus commented Oct 27, 2017

@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.

@sandersaares

This comment has been minimized.

Show comment
Hide comment
@sandersaares

sandersaares Oct 27, 2017

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 commented Oct 27, 2017

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.

@markekraus

This comment has been minimized.

Show comment
Hide comment
@markekraus

markekraus Oct 27, 2017

Collaborator

@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.

Collaborator

markekraus commented Oct 27, 2017

@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.

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Oct 27, 2017

Member

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.

Member

SteveL-MSFT commented Oct 27, 2017

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.

@dragonwolf83

This comment has been minimized.

Show comment
Hide comment
@dragonwolf83

dragonwolf83 Oct 27, 2017

@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.

dragonwolf83 commented Oct 27, 2017

@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.

@afkinsey

This comment has been minimized.

Show comment
Hide comment
@afkinsey

afkinsey Oct 27, 2017

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

afkinsey commented Oct 27, 2017

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

@SteveL-MSFT

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT
Member

SteveL-MSFT commented Oct 27, 2017

@bergmeister

This comment has been minimized.

Show comment
Hide comment
@bergmeister

bergmeister Oct 28, 2017

Contributor

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

Contributor

bergmeister commented Oct 28, 2017

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

@devblackops devblackops referenced this issue Nov 19, 2017

Merged

Project structure refactor #228

7 of 9 tasks complete

theaquamarine added a commit to theaquamarine/PowerShell that referenced this issue Dec 18, 2017

Use pwsh as cmd on non-Windows platforms
powershell.exe is only provided by Windows PowerShell, PSCore
(ie non-Windows) uses pwsh.

PowerShell/PowerShell#4214 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment