Implement -version parameter in console host (address part of https:/…#3115
Implement -version parameter in console host (address part of https:/…#3115daxian-dbw merged 2 commits intoPowerShell:masterPowerShell/PowerShell:masterfrom JamesWTruher:jameswtruher/ShowVersionJamesWTruher/PowerShell-1:jameswtruher/ShowVersionCopy head branch name to clipboard
Conversation
|
@PowerShell/powershell-committee is good with all of this. 👍 |
There was a problem hiding this comment.
redundant extra-line before else #Resolved
There was a problem hiding this comment.
why not simple { get; private set; } #WontFix
There was a problem hiding this comment.
I think it's fine to follow the existing code pattern here. We can convert the style using a tool later. #ByDesign
There was a problem hiding this comment.
There was a problem hiding this comment.
I wonder how it's going to interact with existing in Windows PowerShell
powershell -version 2.0
Since we are stopping to build Windows powershell, and core edition doesn't have any -version 2.0 support, it's probably okey. #ByDesign
There was a problem hiding this comment.
@vors, the @PowerShell/powershell-committee discussed this and that is pretty much the thinking: -version for Windows PowerShell really only supported 2.0 and we're moving away from that. Aligning with Linux convention makes sense. PSCore supports side-by-side intrinsically and using file paths to launch different versions is completely acceptable. #ByDesign
There was a problem hiding this comment.
Furthermore we can always do something like powershell -version:2 if people really demand that functionality in the future (and actually @lzybkr and @BrucePay agreed that it would even be acceptable to do powershell -version 2 as it's highly unlikely that anyone wants to echo one int when they shell out to PowerShell).
There was a problem hiding this comment.
Why are you setting _commandLineCommand here? #Resolved
There was a problem hiding this comment.
There was a problem hiding this comment.
I recommend to use PSVersionInfo.GetPSVersionTable()["GitCommitId"], or even better, add an internal static property GitCommitId right after the PSVersion property at here, and then use PSVersionInfo.GitCommitId here.
Reason: PSVersionInfo has a type initializer, which calls GetCommitInfo() and store the value in a hashtable. the current implementation of GetCommitInfo() reads git commit information from a file, which is slow and this implementation is subject to change (this method may be gone in near future -- we want to generate code at build time to embed the git commit id info, so as to avoid reading a file at startup time). Since the type initializer must run the first time you access a type, it's a waste to call GetCommitInfo() here to read the file again. #Resolved
There was a problem hiding this comment.
There is an extra blank line here. #Resolved
There was a problem hiding this comment.
what would happen if I have powershell -noprofile -noexit -version? #WontFix
There was a problem hiding this comment.
it would report the version and exit - I can add a test for that explicitly if you like. Rather than testing all of the permutations for the parameters, I chose a representative single case
In reply to: 100405816 [](ancestors = 100405816)
…ell#1084) This does not support providing a specific version to run, but like most other *nix commands, -version will now return the version of the PowerShell Engine. 'powershell' is prepended to the output to match other *nix commands. We are using gitcommitid which includes more info about the build.
…on PSVersionInfo Remove extraneous blank lines in files remove line which set the commandline when retrieving the version as it is unneeded
39e0991 to
96abb8f
Compare
#1084
This does not support providing a specific version to run, but
like most other *nix commands, -version will now return the version
of the PowerShell Engine. 'powershell' is prepended to the output to
match other *nix commands. We are using gitcommitid which includes more
info about the build.