c# pdf viewer itextsharp : Reverse page order pdf SDK control project winforms web page .net UWP Windows%20Powershell%20in%20Action%202nd%20Edition7-part1527

40
CHAPTER 2
F
OUNDATIONS
OF
P
OWER
S
HELL
smart—it doesn’t require that you specify the full name of a parameter as long as you 
specify enough for it to uniquely distinguish what you mean. This means you can 
write any of the following
PS (3) > Write-Output -input Hello
Hello 
PS (4) > Write-Output -IN Hello 
Hello 
PS (5) > Write-Output -i Hello 
Hello
and the parameter binder still does the right thing. (Notice that it doesn’t matter 
whether you use uppercase or lowercase letters either.) 
What else does the parameter binder do? It’s in charge of determining how to 
match the types of arguments to the types of parameters. Remember that PowerShell 
is an object-based shell. Everything in PowerShell has a type. For this to work seam-
lessly, PowerShell has to use a fairly complex type-conversion system to correctly put 
things together, a subject that’s covered in chapter 3. When you type a command at 
the  command  line,  you’re  really  typing  strings.  What  happens  if  the  command 
requires a different type of object? The parameter binder uses the type converter to 
try to convert that string into the correct type for the parameter.
Here’s a simple example. Let’s use the 
Get-Process
command to get the process 
with the process 
ID
0. Instead of passing it the number 0, put the argument in quotes 
to force the argument to be a string. This means that the 
-id
parameter, which 
requires a number, will be passed a string instead:
PS (7) > Get-Process -Id "0"
Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)   Id ProcessName 
-------  ------    -----      ----- -----   ------   -- -----------
      0        0         28     0             0 Idle
When  you  attempt to run this command, the parameter  binder detects that 
-id 
needs a number, not a string, so it takes the string “0” and tries to convert it into a 
number. If this succeeds, the command continues, as you see in the example. What 
happens if it can’t be converted? Let’s try it:
PS (8) > Get-Process -Id abc
Get-Process : Cannot bind parameter 'Id'. Cannot convert value "abc" 
to type "System.Int32". Error: "Input string was not in a correct 
format."
At line:1 char:16 
+ Get-Process -Id  <<<< abc 
PS (9) >
You get an error message explaining that the type conversion failed. We’ll discuss this 
in more detail in chapter 3 when we talk about types. Because we’ve introduced the 
use of quotation marks, let’s see one more example. What happens if the argument
Reverse page order pdf - re-order PDF pages in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Customizing Page Order of PDF Document in C# Project
reorder pages in pdf file; how to rearrange pages in a pdf file
Reverse page order pdf - VB.NET PDF Page Move Library: re-order PDF pages in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sort PDF Document Pages Using VB.NET Demo Code
how to move pages within a pdf; pdf page order reverse
T
HE
CORE
CONCEPTS
41
you want to pass to the command starts with a dash? This is where the quotes come 
in. Let’s use 
Write-Output
to print out the string “-InputObject”:
PS (1) > Write-Output -InputObject "-InputObject" 
-InputObject
And it works as desired. Alternatively, you could type this:
PS (2) > Write-Output "-InputObject" 
-InputObject
The quotes keep the parameter binder from treating the quoted string as a parameter.
Another, less frequently used way of doing this is by using the special “end-of-
parameters” parameter, which is two hyphens back to back (
--
). Everything after this 
sequence will be treated as an argument, even if it looks like a parameter. For exam-
ple, using 
--
you can also write out the string 
-InputObject
without using quotes:
PS (3) > Write-Output -- -InputObject
-InputObject
The 
--
sequence tells the parameter binder to treat everything after it as an argument, 
even if it looks like a parameter. This is a convention adopted from the UNIX shells 
and is standardized in the 
POSIX S
hell and Utilities specification.
The final element of the basic command pattern is the switch parameter. These are 
parameters that don’t require an argument. They’re usually either present or absent 
(so obviously  they can’t  be positional). A  good example  of this is the 
-Recurse 
parameter on the 
dir
command. This switch tells the 
dir
command to display files 
from a specified directory as well as all its subdirectories:
PS (1) > dir -Recurse -Filter c*d.exe c:\windows
Directory: Microsoft.PowerShell.Core\FileSystem::C:\windows\
system32
Mode                LastWriteTime     Length Name 
----                -------------     ------ ----
-a---         8/10/2004  12:00 PM     102912 clipbrd.exe 
-a---         8/10/2004  12:00 PM     388608 cmd.exe
PS (2) > 
As you can see, the 
-Recurse
switch takes no arguments.
NOTE
Although it’s almost always the case that  switch parameters 
don’t take arguments, it’s possible to specify arguments to them. We’ll 
save discussion of when and why you might do this for section 7.2.6, 
which focuses on scripts (shell functions and scripts are the only time 
you need this particular feature, so we’ll keep you in suspense for the 
time being).
C# Word: How to Use C# Code to Print Word Document for .NET
document pages in original or reverse order within entire C# Class Code to Print Certain Page(s) of powerful & profession imaging controls, PDF document, image
move pdf pages; how to move pages in a pdf file
42
CHAPTER 2
F
OUNDATIONS
OF
P
OWER
S
HELL
Now that we’ve covered the basic anatomy of the command line, let’s go over the 
types of commands that PowerShell supports.
2.2.3
Command categories
As we mentioned earlier, there are four categories of commands in PowerShell: cmd-
lets, functions, scripts, and native Win32 executables.
Cmdlets
The first category of command is a cmdlet (pronounced “command-let”). Cmdlet is a 
term that’s specific to the PowerShell environment. A cmdlet is implemented by a 
.
NET
class that derives from the 
Cmdlet
base class in the PowerShell Software Devel-
opers Kit 
(SDK)
NOTE
Building cmdlets is a developer task and requires the Power-
Shell 
SDK
. This 
SDK
is freely available for download from Microsoft 
and includes extensive documentation along with many code samples. 
Our goal is to coach you to effectively use and script in the PowerShell 
environment, so we’re not going to do much more than mention the 
SDK
in this book. We’ll look at how to write inline cmdlets when we 
come to the 
Add-Type
cmdlet in later chapters.
This category of command is compiled into a dynamic link library 
(DLL)
and then 
loaded into the PowerShell process, usually when the shell starts up. Because the com-
piled code is loaded into the process, it’s the most efficient category of command to 
execute.
Cmdlets always have names of the form 
Verb-Noun
, where the verb specifies the 
action and the noun specifies the object to operate on. In traditional shells, cmdlets 
correspond most closely to what’s usually called a built-in command. In PowerShell, 
though, anybody can add a cmdlet to the runtime, so there isn’t any special class of 
built-in commands. Cmdlets have the most support in version 1 of PowerShell: full 
online help support, localization, and the best parameter binding support. (Power-
Shell v2 expands this support to fully include scripts and functions; see appendix 
D
.)
In listing 2.1, you can see the 
C
# source code for a simple cmdlet. This cmdlet 
just copies its input to its output. If 
-Parameter1
is specified, its argument will be 
used as a prefix on the output string. We included this example to show you the basic 
structure of a cmdlet. There are a couple of important things to note in this listing. 
The first is the way the parameters are declared using the 
Parameter
attribute. This 
information  is  used  by  the  PowerShell  runtime  to  automatically  determine  the 
parameters for the cmdlet. The cmdlet author doesn’t have to write any code to do 
parameter parsing; the runtime takes care of all this work. Another thing to note is 
the 
ValueFromPipeline=true
notation. This indicates that this parameter may be
T
HE
CORE
CONCEPTS
43
fulfilled by values coming from the pipeline. (We’ll discuss what this means when we 
talk about pipelines later in this chapter.)
[Cmdlet("Write", "InputObject")] 
public class MyWriteInputObjectCmdlet : Cmdlet 
{
[Parameter]      
public string Parameter1;
[Parameter(Mandatory = true, ValueFromPipeline=true)] 
public string InputObject;
protected override void ProcessRecord() 
{
if (Parameter1 != null)
WriteObject(Parameter1 +  ":" +  InputObject);
else
WriteObject(InputObject);
}
If you aren’t a programmer, this listing probably won’t mean much to you. It’s just here 
to show the basic pattern used by PowerShell commands. (When we get to advanced 
functions in chapter 8, you may want to come back and look at this example again.)
Functions
The next type of command is a function. This is a named piece of PowerShell script 
code that lives in memory while the interpreter is running and is discarded on exit. (See 
chapter 7 for more information on how you can load functions into your environ-
ment.) Functions consist of user-defined code that’s parsed once when defined. This 
parsed representation is preserved so it doesn’t have to be reparsed every time it’s used. 
Functions in PowerShell version 1 could have named parameters like cmdlets but 
were otherwise fairly limited. In version 2, this was fixed, and scripts and functions now 
have the full parameter specification capabilities of cmdlets. Notice, though, that the 
same basic structure is followed for both types of commands. The section in the script 
that begins with the 
process
keyword (line 4 of listing 2.2) corresponds to the 
Pro-
cessRecord
method shown in listing 2.1. This allows functions and cmdlets to have 
the same streaming behavior. (See section 2.5.1 for more information on streaming.)
function Write-InputObject 
{
param($Parameter1)        
process {              
if ($Parameter1)
Listing 2.1    C# source code for a simple cmdlet
Class declaration
Marks parameter
Takes pipeline 
input
Process block
Listing 2.2    Source code for a simple shell function command 
Parameters
Process scriptblock
44
CHAPTER 2
F
OUNDATIONS
OF
P
OWER
S
HELL
{
"${Parameter1}:$_"
} else {
"$_"
}
}
Scripts
A script command is a piece of PowerShell code that lives in a text file with a .ps1 
extension. These script files are loaded and parsed every time they’re run, making 
them somewhat slower than functions to start (although once started, they run at the 
same speed). In terms of parameter capabilities, shell function commands and script 
commands are identical. An example of a script is shown in listing 2.3. The astute 
observer will notice that the only difference between this example and the previous 
function example is that the 
function
keyword, the function name, and the braces 
enclosing the body are missing. This is because they aren’t necessary anymore. A 
script takes its name from the name of the file and is delimited by the file itself, so no 
braces are needed. 
param($Parameter1)                       
process {              
if ($Parameter1)
{
"${Parameter1}:$_"
} else {
"$_"
}
Native commands (applications)
The last type of command is called a native command. These are external programs 
(typically executables) that can be executed by the operating system.
NOTE
Choosing names for things is always difficult, and the term 
native command does  sound a bit strange. We had  originally called 
external executables legacy commands, but the feedback was that legacy 
was perceived as being a negative term. On the other hand, simply call-
ing them executables wasn’t suitable, because this class of command 
also includes 
cmd.exe
batch files. In the end, we settled on native com-
mand as sufficiently distinctive.
Because running a native command involves creating a whole new process for the 
command, native commands are the slowest of the command types. Also, native
Listing2.3    Source code for the simple shell script command my-script.ps1
Parameters 
Process scriptblock
T
HE
CORE
CONCEPTS
45
commands do their own parameter processing and so don’t necessarily match the syn-
tax of the other types of commands.
Native commands cover anything that can be run on a Windows computer, so 
you get a wide variety of behaviors. One of the biggest issues is when PowerShell 
waits for a command to finish but it just keeps on going. For example, say you’re 
starting a text document at the command line:
PS (1) > .\foo.txt
PS (2) >
You get the prompt back more or less immediately, and your default text editor will 
pop up (probably 
notepad.exe
because that’s the default). The program to launch 
is  determined  by  the  file  associations  that  are  defined  as  part  of  the  Windows 
environment.
NOTE
In PowerShell, unlike in 
cmd.exe
, you have to prefix a com-
mand with 
./
or 
.\
if you want to run it out of the current directory. 
This is part of PowerShell’s “Secure by Design” philosophy. This par-
ticular security feature was adopted to  prevent Trojan horse attacks 
where the user is lured into a directory and then told to run an innocu-
ous command such as 
notepad.exe
. Instead of running the system 
notepad.exe
, they end up running a hostile program that the attacker 
has placed in that directory and named 
notepad.exe
. Chapter 21 cov-
ers the security features of the PowerShell environment in detail.
What about when you specify the editor explicitly?
PS (2) > notepad foo.txt
PS (3) >
The same thing happens—the command returns immediately. But what about when 
you run the command in the middle of a pipeline?
PS (3) > notepad foo.txt | sort-object 
<exit notepad>
PS (4) >
Now PowerShell waits for the command to exit before giving you back the prompt. 
This can be handy when you want to insert something such as a graphical form editor 
in the middle of a script to do some processing. This is also the easiest way to make 
PowerShell wait for a process to exit.
Finally, let’s run the 
edit.com
program. This is the old console-based full screen 
editor included with 
MS-DOS
and Windows since about 
DOS
4.0. (This also works 
with other console editors—vi, Emacs, and so forth.)
PS (6) > edit.com ./foo.txt
PS (7) >
46
CHAPTER 2
F
OUNDATIONS
OF
P
OWER
S
HELL
As you’d expect, the editor starts up, taking over the console window. You can edit the 
file and then exit the editor and return to PowerShell. As you can see, the behavior of 
native commands depends on the type of native command, as well as where it appears 
in the pipeline.
A useful thing to remember is that the PowerShell interpreter itself is a native com-
mand: 
powershell.exe
. This means you can call PowerShell from within Power-
Shell. When you do this, a second PowerShell process is created. In practice there’s 
nothing unusual about  this—that’s basically how all  shells work. PowerShell just 
doesn’t have to do it very often, making it much faster than conventional shell lan-
guages. 
The ability to run a child PowerShell process is particularly useful if you want to 
have isolation in portions of your script. A separate process means that the child script 
can’t impact the caller’s environment. This feature is useful enough that PowerShell 
has special handling for this case, allowing you to embed the script to run inline. If 
you want to run a fragment of script in a child process, you can do so by passing the 
block of script to the child process delimited by braces. Here’s an example:
PS {1) > powershell { Get-Process *ss } | Format-Table name, handles
Name                                                Handles 
----                                                -------
csrss                                                  1077 
lsass                                                  1272 
smss                                                     28
There are two things to note in this example. The script code in the braces can be any 
PowerShell code, and it will be passed through to the new PowerShell process. The 
special handling takes care of encoding the script in such a way that it’s passed prop-
erly to the child process. The other thing to note is that, when PowerShell is executed 
this way, the output of the process is serialized objects—the basic structure of the out-
put is preserved—and so can be passed into other commands. We’ll look at this seri-
alization in detail when we cover remoting—the ability to run PowerShell scripts on a 
remote computer—in chapter 12.
Now that we’ve covered all four PowerShell command types, let’s get back to 
looking at the PowerShell syntax. Notice that a lot of what we’ve examined so far is a 
bit verbose. This makes it easy to read, which is great for script maintenance, but it 
looks like it would be a pain to type on the command line. PowerShell addresses these 
two conflicting goals—readability and writeability—with the concept of elastic syn-
tax. Elastic syntax allows you to expand and collapse how much you need to type to 
suit your purpose. We’ll see how this works in the next section.
A
LIASES
AND
ELASTIC
SYNTAX
47
2.3
A
LIASES
AND
ELASTIC
SYNTAX
We haven’t talked about aliases yet or how they’re used to achieve an elastic syntax in 
PowerShell. Because this concept is important in the PowerShell environment, we 
need to spend some time on it. 
The cmdlet 
Verb-Noun
syntax, while regular, is, as we noted, also verbose. You may 
have noticed that in most of the examples we’re using commands such as 
dir
and 
type
. The trick behind all this is aliases. The 
dir
command is really 
Get-ChildItem
and the 
type
command is really 
Get-Content
. You can see this by using the 
Get-
Command
command:
PS (1) > get-command dir
CommandType     Name                  Definition 
-----------     ----                  ----------
Alias           dir                   Get-ChildItem
This tells you that the command is an alias for 
Get-ChildItem
. To get information 
about the 
Get-ChildItem
command, you then do this
PS (2) > get-command get-childitem
CommandType     Name                  Definition 
-----------     ----                  ----------
Cmdlet          Get-ChildItem         Get-ChildItem [[-P...
which truncates the information at the width of the console window. To see all the 
information, pipe the output of 
Get-Command
into 
fl
:
PS (3) > get-command get-childitem | fl 
Name             : Get-ChildItem 
CommandType      : Cmdlet 
Definition       : Get-ChildItem [[-Path] <String[]>] [[-Filter]
<String>] [-Include <String[]>] [-Exclude <S
tring[]>] [-Recurse] [-Force] [-Name] [-Verbo
se] [-Debug] [-ErrorAction <ActionPreference>
] [-ErrorVariable <String>] [-OutVariable <St
ring>] [-OutBuffer <Int32>]
Get-ChildItem [-LiteralPath] <String[]> [[-Fi
lter] <String>] [-Include <String[]>] [-Exclu
de <String[]>] [-Recurse] [-Force] [-Name] [-
Verbose] [-Debug] [-ErrorAction <ActionPrefer
ence>] [-ErrorVariable <String>] [-OutVariabl
e <String>] [-OutBuffer <Int32>]
Path             :
AssemblyInfo     : 
DLL              : C:\WINDOWS\assembly\GAC_MSIL\Microsoft.PowerS
hell.Commands.Management\1.0.0.0__31bf3856ad3
64e35\Microsoft.PowerShell.Commands.Managemen
t.dll
HelpFile         : Microsoft.PowerShell.Commands.Management.dll-
Help.xml
ParameterSets    : {Items, LiteralItems}
ImplementingType : Microsoft.PowerShell.Commands.GetChildItemCom
48
CHAPTER 2
F
OUNDATIONS
OF
P
OWER
S
HELL
mand
Verb             : Get 
Noun             : ChildItem
This shows you the full detailed information about this cmdlet. But wait—what’s the 
fl
command? Again you can use 
Get-Command
to find out:
PS (4) > get-command fl
CommandType     Name                  Definition 
-----------     ----                  ----------
Alias           fl                    Format-List
PowerShell comes with a large set of predefined aliases. There are two basic categories 
of aliases—transitional aliases and convenience aliases. By transitional aliases, we mean 
a set of aliases that map PowerShell commands to commands that people are accus-
tomed to using in other shells, specifically 
cmd.exe
and the UNIX shells. For the 
cmd.exe
user, PowerShell defines 
dir
type
copy
, and so on. For the UNIX user, 
PowerShell defines 
ls
cat
cp
, and so forth. These aliases allow a basic level of func-
tionality for new users right away.
The other set of aliases are the convenience aliases. These aliases are derived from 
the  names  of  the  cmdlets  they  map  to.  So 
Get-Command
becomes 
gcm
Get-
ChildItem
becomes 
gci
Invoke-Item
becomes 
ii
, and so on. For a list of the 
defined aliases, type 
Get-Alias
at the command line. You can use the 
Set-Alias 
command (whose alias is 
sal
, by the way) to define your own aliases.
NOTE
Aliases  in  PowerShell  are  limited  to  aliasing  the  command 
name only. Unlike in other systems such as ksh, bash, and zsh, Power-
Shell aliases can’t take parameters. If you need to do something more 
sophisticated than simple command-name translations, you’ll have to 
use shell functions or scripts.
This is all well and good, but what does it have to do with elastics? Glad you asked! 
The idea is that PowerShell can be terse when needed and descriptive when appropri-
ate. The syntax is concise for simple cases and can be stretched like an elastic band for 
larger problems. This is important in a language that is both a command-line tool 
and a scripting language. The vast majority of “scripts” that you’ll write in PowerShell 
will be no more than a few lines long. In other words, they’ll be a string of commands 
that you’ll type on the command line and then never use again. To be effective in this 
environment, the syntax needs to be concise. This is  where  aliases like 
fl
come 
in—they allow you to write concise command lines. When you’re scripting, though, 
it’s best to use the long name of the command. Sooner or later, you’ll have to read the 
script you wrote (or—worse—someone else will). Would you rather read something 
that looks like this
gcm|?{$_.parametersets.Count -gt 3}|fl name
or this?
A
LIASES
AND
ELASTIC
SYNTAX
49
get-command |
where-object {$_.parametersets.count -gt 3} |
format-list name
I’d certainly rather read the latter. (As always, we’ll cover the details of these examples 
later in the book.)
NOTE
PowerShell has two (or more) names for many of the same 
commands. Some people find this unsettling—they prefer having only 
one way of doing things. In fact, this “only one way to do it” principle 
is also true for PowerShell, but with a significant variation: we wanted 
to have one best way of doing something for each particular scenario or 
situation. Fundamentally this is what computers are all about; at their 
simplest, everything is just a bunch of bits. To be practical, you start 
from the simple bits and build solutions that are more appropriate for 
the problem you’re trying to solve. Along the way, you create an inter-
mediate-sized component that may be reused to solve other problems. 
PowerShell uses this same approach: a series of components at different 
levels  of  complexity  intended  to  address  a  wide  range  of  problem 
classes. Not every problem is a nail, so having more tools than a ham-
mer is a good idea even if requires a bit more learning.
There’s a second type of alias used in PowerShell: parameter aliases. Unlike command 
aliases, which can be created by end users, parameter aliases are created by the author 
of a cmdlet, script, or function. (You’ll see how to do this when we look at advanced 
function creation in chapter 8.)
A parameter alias is just a shorter name for a parameter. But wait a second. Earlier 
we said that you just needed enough of the parameter name to distinguish it from 
other command parameters. Isn’t this enough for convenience and elasticity? So why 
do you need parameter aliases? The reason you need these aliases has to do with script 
versioning. The easiest way to understand versioning is to look at an example. 
Say you have a script that calls a cmdlet 
Process-Message
. This cmdlet has a 
parameter 
-Reply
. You write your script specifying just
Process-Message 
-Re
Run the script, and it works fine. A few months later, you install an enhanced version 
of the 
Process-Message
command. This new version introduces a new parameter: 
-receive
. Just specifying 
-Re
is no longer sufficient. If you run the old script with 
the new cmdlet, it will fail with an ambiguous parameter message. In other words, the 
script is broken. 
How do you fix this with parameter aliases? The first thing to know is that Power-
Shell always picks the parameter that exactly matches a parameter name or alias over a 
partial match. By providing parameter aliases, you can achieve pithiness without also 
making scripts subject to versioning issues. (We do recommend always using the full
Documents you may be interested
Documents you may be interested