As soon as you find the command that you must have for a particular task you can use its help file to
learn how to use it.
Although the examples are obviously a great way to do that learning to interpret the help files syntax
can enable you quickly find to commands capabilities so that you can run it more easily.
You can use their help for go out there and look as an example that command features two parameter sets.
Each feature represents one way in which the command can be run.
Notice that each parameter set has many parameters and several parameters in common.
You can make sound merge parameters between sets.
That is if you decide to use the list parameter you cannot also use the shlock name because those two
do not appear together in the same perimeter set in the first perimeter set.
The log name perimeter is mandatory.
This is indicated by the whole parameter not be an enclosed in square brackets.
Help also shows that the perimeter accepts Drian Well yes men in strings of letters numbers or other
characters.
The actual log name parameter name is listed in square brackets meaning it is a positional perimeter
that command cannot be around without a lot name but you do not have to actually type shlock name parameter
name.
You have to pass the log names Korean in the first position because that is the position in the Help
file where the log name parameter appears there for the following two commands are functionally equal
and get their share around lock.
There's a log name application.
And the second command get Desch event lock application again because log name parameter is the positional
parameter.
We can skip it.
We don't have to type it to note here that more information about each parameter can be found by viewing
the commands for help.
For example around help get Desha won't lock dush fool to see the full Calpol forgat event log.
And notice the additional information display you can for example confirm that the log name parameter
is mandatory.
And it appears in the first position.
Be cautious when a meeting parameter names.
One reason for caution is that you cannot do so with every parameter.
The first computer name parameter.
As one example can not have the parameter name emitted.
Another reason for caution is that you can quickly lose track of what goes where when you provide perimeter
names and parameters can come in any order.
So try type and get to and lock computer name or example Leptis it to a log name application Midwest
town that'll get to the nearest town records for application log for computer lab DC to how many are
made to parameter name you become responsible for everything in the correct order.
As for example get around to lock Desch computer name will have to sit to application.
This command will not work because the log name is being parsed in the wrong position.
So the best practice for you that if you are just getting started with Windows powers shell try to provide
full parameter names instead of pass and parameter well used by position for parameter names make commands
easier to read and troubleshoot.
And they make it easier to see when you are typing the command incorrectly some votes about fool help
although the brief syntax section of the help file can be used as a quick reminder.
It doesn't provide a higher level of detail about each parameter read and it commands full help provides
much deeper detail.
For example around get help get service full and see how much additional information you receive.
Some additional information includes the following description of each parameter whether each parameter
has a default.
Well you know whether a parameter is mandatory whether a parameter can accept failure and is tific position
and whether a perimeter accepts pipeline input and if this is the case how so for help also includes
extended command descriptions and examples.