-
Notifications
You must be signed in to change notification settings - Fork 98
Make -Path a required parameter for Save-PSResource cmdlet #780
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
else { | ||
resolvedPath = SessionState.Path.GetResolvedPSPathFromPSPath(value).First().Path; | ||
} | ||
if (WildcardPattern.ContainsWildcardCharacters(value)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think instead of checking for wildcards here we should try to resolve the path and if that throws, catch and display the error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That way if there's any issues at all with the path we can properly handle and emit the error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with wildcards in the path is that they can return multiple matches, and then which path do we use? Whatever we choose will not be apparent to the user, unless we write out a message.
I feel we should not support wildcards in this case, and require the user to provide a single path that resolves to a real location. If not then that is a terminating error. We don't need to test the path and return an error, because GetResolvedPSPathFromPSPath
already does this and throws an exception with a readable error:
"Cannot find path 'C:\temp\temp' because it does not exist."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, this makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
else { | ||
resolvedPath = SessionState.Path.GetResolvedPSPathFromPSPath(value).First().Path; | ||
} | ||
if (WildcardPattern.ContainsWildcardCharacters(value)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with wildcards in the path is that they can return multiple matches, and then which path do we use? Whatever we choose will not be apparent to the user, unless we write out a message.
I feel we should not support wildcards in this case, and require the user to provide a single path that resolves to a real location. If not then that is a terminating error. We don't need to test the path and return an error, because GetResolvedPSPathFromPSPath
already does this and throws an exception with a readable error:
"Cannot find path 'C:\temp\temp' because it does not exist."
Make -Path a required parameter for Save-PSResource cmdlet
PR Summary
This PR makes
-Path
a required parameter forSave-PSResource
cmdlet and changes its logic.PR Context
PR Checklist
.h
,.cpp
,.cs
,.ps1
and.psm1
files have the correct copyright headerWIP:
or[ WIP ]
to the beginning of the title (theWIP
bot will keep its status check atPending
while the prefix is present) and remove the prefix when the PR is ready.