Add Microsoft.PowerShell.UnixCompleters module#44
Add Microsoft.PowerShell.UnixCompleters module#44TravisEz13 merged 13 commits intoPowerShell:masterfrom
Conversation
Modules/Microsoft.PowerShell.UnixCompleters/Microsoft.PowerShell.UnixCompleters.psd1
Show resolved
Hide resolved
| CompanyName = 'Microsoft Corporation' | ||
|
|
||
| # Copyright statement for this module | ||
| Copyright = '© Microsoft Corporation' |
There was a problem hiding this comment.
Should we replace the Unicode with "(C)"?
There was a problem hiding this comment.
Could do if that's deemed to be more appropriate
There was a problem hiding this comment.
I believe convention is to stick with ASCII where possible, so use (c) (lowercase c)
| Description = 'Get parameter completion for native Unix utilities. Requires zsh or bash.' | ||
|
|
||
| # Minimum version of the PowerShell engine required by this module | ||
| PowerShellVersion = '6.0' |
There was a problem hiding this comment.
No, but I saw no reason to limit it. There's no constraint I can think of (other than possibly the .NET version) that would stop it from working on downlevel PowerShell versions. Certainly I tested it with 6.2 and it worked fine.
There was a problem hiding this comment.
Why I don't see GitHub "Resolved" button?
There was a problem hiding this comment.
Why I don't see GitHub "Resolved" button?
Oh interesting! Perhaps it's linked to being a "member" or "contributor" of some other privileged role?
| PowerShellVersion = '6.0' | ||
|
|
||
| # Name of the PowerShell host required by this module | ||
| # PowerShellHostName = '' |
There was a problem hiding this comment.
Please remove commented and unused lines.
| # RequiredAssemblies = @() | ||
|
|
||
| # Script files (.ps1) that are run in the caller's environment prior to importing this module. | ||
| ScriptsToProcess = @("OnStart.ps1") |
There was a problem hiding this comment.
I think the name should be more specific and correlate with the module name.
There was a problem hiding this comment.
Well it's already encapsulated by the module. We can't call every script in a module "Microsoft.PowerShell.UnixCompleters.OnStart.ps1". What would you call it?
There was a problem hiding this comment.
I'd be ok with short name until users do not see them in logs, traces and so on. Otherwise full module name prefix is good.
There was a problem hiding this comment.
If we had to name every script in a module like that it would get ridiculous. The name of the script is contextual to the module
.../Microsoft.PowerShell.UnixCompleters/Microsoft.PowerShell.UnixCompleters/ZshUtilCompleter.cs
Show resolved
Hide resolved
| using (var zshProc = new Process()) | ||
| { | ||
| zshProc.StartInfo.RedirectStandardOutput = true; | ||
| zshProc.StartInfo.RedirectStandardError = true; | ||
| zshProc.StartInfo.FileName = this._zshPath; | ||
| zshProc.StartInfo.Arguments = arguments; | ||
|
|
||
| zshProc.Start(); | ||
|
|
||
| return zshProc.StandardOutput.ReadToEnd(); | ||
| } |
There was a problem hiding this comment.
The same about using and Process() initialization.
| .ToString(); | ||
| } | ||
| } | ||
| } No newline at end of file |
Modules/Microsoft.PowerShell.UnixCompleters/tests/Completion.Tests.ps1
Outdated
Show resolved
Hide resolved
…ll.UnixCompleters/BashUtilCompleter.cs Co-Authored-By: Ilya <darpa@yandex.ru>
|
@iSazonov while I'm grateful for the review, this is really just me checking in code from https://github.com/rjmholt/PSUnixUtilCompleters, which has already been released. I'm probably not going to make any major edits in this PR, since it's just a migration. |
|
@iSazonov I've addressed the easier parts of your feedback. I've left the constants and the string localisation |
|
@SteveL-MSFT this should be ready to merge now |
...Microsoft.PowerShell.UnixCompleters/Microsoft.PowerShell.UnixCompleters/BashUtilCompleter.cs
Outdated
Show resolved
Hide resolved
...l.UnixCompleters/Microsoft.PowerShell.UnixCompleters/Commands/ImportUnixCompletersCommand.cs
Outdated
Show resolved
Hide resolved
...l.UnixCompleters/Microsoft.PowerShell.UnixCompleters/Commands/RemoveUnixCompletersCommand.cs
Outdated
Show resolved
Hide resolved
...icrosoft.PowerShell.UnixCompleters/Microsoft.PowerShell.UnixCompleters/UnixUtilCompletion.cs
Outdated
Show resolved
Hide resolved
| $null = Register-EngineEvent -SourceIdentifier PowerShell.OnIdle -MaxTriggerCount 1 -Action { | ||
| $m = Get-Module PSUnixUtilCompleters | ||
| $m.OnRemove = { | ||
| Write-Verbose "Deregistering UNIX native util completers" |
There was a problem hiding this comment.
This is better moved to a psm1 file, where you can use $MyInvocation.MyCommand.Module.OnRemove.
There was a problem hiding this comment.
After actually trying this out, it doesn't seem to work: $MyInvocation.MyCommand.Module is null, I suspect because the psm1 being run is still in the dot-source phase; it hasn't been created as a module yet. That's why I had to be tricky with that event
There was a problem hiding this comment.
Try $MyInvocation.MyCommand.ScriptBlock.Module.OnRemove instead. This one should work.
| CompleterGlobals.CompletedCommands = utilsToComplete; | ||
| CompleterGlobals.UnixUtilCompleter = utilCompleter; | ||
|
|
||
| RegisterCompletersForCommands(utilsToComplete); |
There was a problem hiding this comment.
Will there be a problem if the module gets imported to two Runspaces? namely, Register-ArgumentCompleter would be called twice for each of the same native utility.
There was a problem hiding this comment.
Quite likely. I don't think it's threadsafe either (nor is the underlying mechanism for Register-ArgumentCompleter; it's not a ConcurrentDictionary<,>). But as a module intended solely for interactive scenarios, I'm thinking of multithreaded/multirunspace scenarios as out of scope for now.
No description provided.