Nov 18th, 2021 Community Call
SteveL-MSFT opened this issue · 21 comments
Agenda:
- Welcome Michael (Michael)
- December Community Call? (Steve)
- 7.2 GA (Steve)
- 7.3 roadmap (Steve)
- PS7 in Windows? (Steve)
- VSCode-Extension update (Sydney/Andy)
- PowerShellGallery migration (Amber)
- How can the community help the team? (Jason)
- Updateable Help Update (Aditya)
- PSScriptAnalyzer docs (Sean)
- PSReadLine 2.2 update (Dongbo)
- Q&A
Pre-load questions/topics please!
Congrats on 7.2 LTS!
I suppose the obvious next agenda is some of the initial ideas/themes of what the 7.3 roadmap will look like.
... the world always has been, the world is, and the world always will be a messy place ...
so what about a possibility to delete wrong/unneeded History entries (e.g. Typos)
from PredictionSource ListView.
Highlight/select it and delete it from the history with a PSReadline KeyHandler?
Or maybe something already exists which I don't know?
@WorrenB PSReadLine doesn't provide a way to delete history entries, because it adds complexity to how the history entries are synced among different sessions today. So if you want to fix up your history, you will need to manually editing the history file, and make sure to close all powershell instances before doing that to avoid those entries lingering in the cache.
But there are ways for you to reduce typos in your command-line history -- ValidateAndAcceptLine function and the CommandValidationHandler.
You can bind the Enter key with ValidateAndAcceptLine, so when you press Enter it will validate the commands before accepting it as input to PS engine. Here is an example:
You can also leverage Set-PSReadLineOption -CommandValidationHandler for more sophisticated validating and checks before accepting an input, or even altering the input to fix the typo. For example:
# Auto correct 'git cmt' to 'git commit'
Set-PSReadLineOption -CommandValidationHandler {
param([CommandAst]$CommandAst)
switch ($CommandAst.GetCommandName())
{
'git' {
$gitCmd = $CommandAst.CommandElements[1].Extent
switch ($gitCmd.Text)
{
'cmt' {
[Microsoft.PowerShell.PSConsoleReadLine]::Replace(
$gitCmd.StartOffset, $gitCmd.EndOffset - $gitCmd.StartOffset, 'commit')
}
}
}
}
}What would help help as well is storing how often a suggestion was accepted so that the first few suggestions can be ordered by 'popularity'. But I understand this of course that the effort for that is quite involving as PowerShell would need another file as a local database for that.
What would help help as well is storing how often a suggestion was accepted so that the first few suggestions can be ordered by 'popularity'. But I understand this of course that the effort for that is quite involving as PowerShell would need another file as a local database for that.
The suggestion provider is extensible so someone can always fork and make one like that :)
We do have similar issues opened:
General topics:
- steering committees
- general roadmap for 7.3
- future for providers (SHiPS is parked?)
- Gallery improvements/roadmap
- classes/language feature prioritization
- how can the community help the team more?
Trying to run an EXE which can't start because of a missing DLL on Windows doesn't result in any message on the Error stream. There should be an option to enable that.
Trying to run an EXE which can't start because of a missing DLL on Windows doesn't result in any message on the Error stream. There should be an option to enable that.
@sba923 That sounds more like an issue with the EXE in question than with PowerShell. If the EXE doesn't output to stderr the PowerShell can't pick up anything on the Error stream.
The EXE can't display anything 'cos it doesn't even start. The parent process needs to report it cannot start the child, in that case with unhandled exception 0xC0000135 (STATUS_DLL_NOT_FOUND) in that particular case.
@sba923 can you check out the value of $LASTEXITCODE after failed to run the EXE from PowerShell? If the value is non-zero, then PowerShell already reported that the child process failed.
Also, If you run that EXE from cmd.exe, will any error message be generated? If not, then it's likely just no error got emitted from the child process, and there is no way for the parent process to know why it failed.
Yes, PowerShell does indicate, via $LASTEXITCODE, that the command has failed:
But the point is, especially when running interactively, that the failure is "silent." One has to look up the error code to determine what's going on.
CMD, on the other hand, has an exception handler that displays a message box informing the user of the actual cause of the failure:
My suggestion is inspired by MKS Korn Shell's set -X option (@BrucePay will remember...):
From set KornShell flags and positional parameters:
Of course, that exception is not desirable for scripted / unattended execution, so it should be off by default.
It doesn't have to be a GUI-based one, hence my suggestion to output the explanatory text to the Error stream.
@sba923 can you reference this in a new issue in the main PowerShell repo to ensure that it can be tracked properly
CMD, on the other hand, has an exception handler that displays a message box informing the user of the actual cause of the failure:
I don't think the message box is generated by CMD. Is adb a console application (CUI) or a windows application (GUI)?
Please open an issue and the discussion can happen there.
adb is a console app. I will open an issue.
@sba923 I can confirm the behaviour appears to be different for each shell that executes adb with a missing dll. Once you've opened an issue could you tag me in it or let me know here and I'll add to it with some of the repro steps I've taken.
Apologies for asking this stupid question but why connect-AzureAD cmdlet is getting failed on PowerShell 7.2?
Also would like to know if we can us PowerShell 7 with well known Intune app id in order to interact with Intune backend Graph API for running scripts non interactively?
@ashisharya65 About the AzureAD module, it's not .NET Core compatible. See details at PowerShell/PowerShell#11932 (comment). As a workaround, import the module with -UseWindowsPowerShell.
My personal preferences for roadmap:
- FileSystem provider improvements
- New remoting subsystem
Also it would be great to see Work Groups with new members and working every day.
Keep in mind! Some Corporation security policies will block PowerShell 7 implementation due to frequent updates. I take it as my responsibility to help in the adoption in order to be implemented correctly to the people to use it.
Unfortunately, the issue with 7.2.0 missing the correct help docs URL has stopped my progress to have it roll out to the next release, in order to replace the one currently approved (7.1.3).
But WAIT!! I know what I need do in order to get the correct docs for 7.2.. Think outside of the box!!
This Why I love PowerShell!!
Happy Birthday!! :)