Skip to content
This repository was archived by the owner on Dec 8, 2021. It is now read-only.

Add Microsoft.PowerShell.UnixCompleters module#44

Merged
TravisEz13 merged 13 commits intoPowerShell:masterfrom
rjmholt:unixcompleters
Apr 13, 2020
Merged

Add Microsoft.PowerShell.UnixCompleters module#44
TravisEz13 merged 13 commits intoPowerShell:masterfrom
rjmholt:unixcompleters

Conversation

@rjmholt
Copy link
Contributor

@rjmholt rjmholt commented Feb 14, 2020

No description provided.

@rjmholt
Copy link
Contributor Author

rjmholt commented Feb 20, 2020

@SteveL-MSFT

CompanyName = 'Microsoft Corporation'

# Copyright statement for this module
Copyright = '© Microsoft Corporation'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we replace the Unicode with "(C)"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could do if that's deemed to be more appropriate

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this tested on 6.0?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why I don't see GitHub "Resolved" button?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 = ''
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the name should be more specific and correlate with the module name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +98 to +108
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();
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same about using and Process() initialization.

.ToString();
}
}
} No newline at end of file
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add new line.

…ll.UnixCompleters/BashUtilCompleter.cs

Co-Authored-By: Ilya <darpa@yandex.ru>
@rjmholt
Copy link
Contributor Author

rjmholt commented Feb 21, 2020

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

@rjmholt
Copy link
Contributor Author

rjmholt commented Mar 19, 2020

@iSazonov I've addressed the easier parts of your feedback. I've left the constants and the string localisation

@rjmholt
Copy link
Contributor Author

rjmholt commented Mar 19, 2020

@SteveL-MSFT this should be ready to merge now

Copy link
Member

@TravisEz13 TravisEz13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My issues are resolved

$null = Register-EngineEvent -SourceIdentifier PowerShell.OnIdle -MaxTriggerCount 1 -Action {
$m = Get-Module PSUnixUtilCompleters
$m.OnRemove = {
Write-Verbose "Deregistering UNIX native util completers"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is better moved to a psm1 file, where you can use $MyInvocation.MyCommand.Module.OnRemove.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try $MyInvocation.MyCommand.ScriptBlock.Module.OnRemove instead. This one should work.

CompleterGlobals.CompletedCommands = utilsToComplete;
CompleterGlobals.UnixUtilCompleter = utilCompleter;

RegisterCompletersForCommands(utilsToComplete);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@rjmholt rjmholt Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point.

@TravisEz13 TravisEz13 merged commit a82fd29 into PowerShell:master Apr 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants