turn off unapproved verbs warning #27030
Replies: 4 comments 4 replies
-
|
I hate the idea. Developers shoud just use approved verbs. There really is no excuse, other than 'I am special'. Approved verbs are part of the Powershell Promise. I am reluctant to want this. |
Beta Was this translation helpful? Give feedback.
-
|
Even if I write scripts for myself? And even if (as a user) I feel like turning off a warning for what others have already written despite your opinion? And even when my verb explains what is happening better than any "approved" verb? Why is it better to not know what is happening by reading the function name as long as it is on some list? I have a command Login-AWS. Guess what it does. If you guessed login to AWS, then I choose the name well. I don't see any approved verb that fits that. The Powershell developers are not going to be able to think of every action that anyone might ever take for the rest of time. I do agree that the Powershell language team should try to stick to their list, and they can add a verb with any new revision of Powershell if they find it prudent to add a function that does something new, but not every independent private programmer in the world. I do generally try to follow the Powershell suggestion of using a verb and noun, but sometimes I like mine better. And, that was always a suggestion. This warning message never happened until recently. I know I can use the Import-Module command and disable the warning, but generally I rely on the automatic module importing feature that Powershell introduced long ago. And right now, I don't want my program flow to be interrupted by any nonstandard verb. Why should an option not be created to allow me to turn that off if that is what I want? There are all kinds of options like that already. Why is this issue so special? I usually turn on strict mode, but that is not forced onto everyone. |
Beta Was this translation helpful? Give feedback.
-
|
You are rarely the first person to come up with a concept. When in doubt you can check what other people have done to handle your scenario. VMWare uses Thanks to these common design patterns I know to look for |
Beta Was this translation helpful? Give feedback.
-
|
I don't like verb standardization at all. And I think it would be better to make it a desirable rule rather than a law. |
Beta Was this translation helpful? Give feedback.
-
Also known as Separation of mechanism and policy Should PowerShell be restrictive by default and then users have to relax constraints, or the reverse where you have to harden an installation? I am sure that PowerShell requiring scripts to be signed by default was a nail in the coffin for many users, but welcomed by IT departments. |
Beta Was this translation helpful? Give feedback.
-
This should work I'm not sure on this but to know for sure you'd need to start looking a debugging the Module Import process I'm pretty sure there are Performance benefits to using the approved verbs (like not kicking off that warning message) as well as the benefits of others being much more able to discover them
Yeah go for it - the team of original developers very much did think of the issues with discoverability which is why the list of Approved Verbs is a You can get around this completely by not using the Verb-Noun naming convention and then adding whatever verb you may want instead function mycommand {
[CmdletBinding()]
[Alias('NotA-RealCommand')]
param()
123
}& that bypasses the Unapproved Verb warning without the above suggestion even if a bit convoluted doing it this way (& helped me find a bug too) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. That helps. I didn't know that was possible. Instead of Powershell auto-importing the "offending module", I still have to add the Import-Module command for any module that has verbs that I want to ignore, which you helped me think of. But, at least I can get where I want to be for repeated use of common modules. So, I think that's a decent work-around. |
Beta Was this translation helpful? Give feedback.
-
|
@kilasuit Trying to import my modules in my $profile caused a delay of about 6 seconds and sometimes twice that in loading a session of PowerShell. I renamed all my functions to use a sanctioned verb with an alias (without importing in the profile) and that works just fine too, without the delay. Also, based on Get-Command, I created a function to list the commands with alias from a module, showing only the latest version. So, using the alias or not, that is helpful to find commands from a module. Example: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I would like Powershell to have a setting like $UnapprovedVerbPreference or something that I can set to ignore in my profile script.
I wrote a module that has unapproved verbs, and recently, the first time I run a function from that module, I get a long yellow warning message about the module having unapproved verbs. And, the function takes much longer to run than it used to. It seems like those two things are linked. I will name my functions whatever I want. I don't need this smack-down from Powershell just because I decided to do something the Powershell team never thought of. Isn't that the point of writing code?
Beta Was this translation helpful? Give feedback.
All reactions