PowerShell权威指南：比较与实践

Powershell

需积分: 9 15 浏览量更新于2024-07-29 收藏 3.89MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

POWERSHELL AND CMD.EXE 11

A.1.9 Using doskey in PowerShell

The

doskey

tool lets you define keyboard macros in a console window. What do we

mean by this?

Doskey

macros are processed by the console subsystem—the part of

the Windows operating system that handles rendering the console window and read-

ing from the keyboard. When a console program does a

Readline()

call, the console

subsystem checks to see whether any macros are available for that program. If there

are, it does the macro substitution on the string before they’re returned to the user.

NOTE Because

doskey

relies on the console infrastructure, it only

applies to console programs.

powershell_ise.exe

isn’t a console

program, so the things we’re discussing here don’t apply to it.

Why do we care? Because it means we can also use

doskey

macros in PowerShell.

Here’s an example that shows how to use the

doskey

utility from PowerShell. First

look to see whether any macros are defined for PowerShell initially:

PS (2) > doskey /macros:powershell.exe

Nothing is returned, so, obviously, there are currently no

doskey

macros for Power-

Shell. Notice that you have to specify the full name of the executable file. The default

cmd.exe

, so to make the

doskey

commands apply to PowerShell, you always have

to specify the name

powershell.exe

. Let’s define a macro:

PS (3) > doskey /exename=powershell.exe `

>> ddir = dir `$* `| ? `{ '$_.PSIsContainer' `}

This requires a fair bit of quoting to make sure the arguments get passed through to

doskey

properly. If you want to define a number of macros, it’s probably easiest to

define them using the

doskey /file

option.

Now let’s make sure the macro was defined properly. Remember, the text will be

substituted on the command line, so the resulting command line has to be syntacti-

cally correct:

PS (4) > doskey /macros:powershell.exe

ddir=dir $* | ? { $_.PSIsContainer }

It looks fine. Notice the use of

in the macros. When

doskey

macro substitution is

done,

will be replaced by any arguments to the macro. Let’s try it:

PS (5) > ddir

Directory: Microsoft.PowerShell.Core\FileSystem::C:\files

Mode LastWriteTime Length Name

---- ------------- ------ ----

d---- 8/19/2006 2:35 PM d1

d---- 8/19/2006 2:36 PM d2

d---- 8/19/2006 2:35 PM d3

14 COMPARING POWERSHELL TO OTHER LANGUAGES

or access WMI:

c:\>powershell Get-WmiObject Win32_Bios

SMBIOSBIOSVersion : 7SET33WW (1.19 )

Manufacturer : LENOVO

Name : Ver 1.00PARTTBL

SerialNumber : LVB7KY3

Version : LENOVO - 1190

You can even mix and match commands on the same line. In the following, you use the

find

utility to extract the lines containing “Ver” from the output of

Get-WmiObject

c:\>powershell Get-WmiObject Win32_Bios | find "Ver"

SMBIOSBIOSVersion : 7SET33WW (1.19 )

Name : Ver 1.00PARTTBL

Version : LENOVO - 1190

It’s also possible to do PowerShell piping in the same command that uses

cmd.exe

piping. You have to put the pipe symbol in double quotes:

c:\>powershell Get-Process "|" foreach {$_.Name} | find "cs"

csrss

In this example, you call

Get-Process

to get a list of running processes and then

pipe this output into the

foreach

command, which extracts name from the objects.

The overall output from

powershell.exe

is then passed into

find

through

cmd.exe

’s implementation of pipes.

Passing unknown arguments into the interpreter usually works fine, but there is a

case where this causes problems: when you mistype a switch to

powershell.exe

This gets passed to the interpreter, which then emits the following rather incompre-

hensible error:

c:\>powershell -badoption

Missing expression after unary operator '-'.

At line:1 char:2

+ - <<<< badoption

+ CategoryInfo : ParserError: (-:String) [], ParentCont

ainsErrorRecordException

+ FullyQualifiedErrorId : MissingExpressionAfterOperator

What’s happening here is that the interpreter is trying to parse the string it received. It

understands that

is a valid operator, but what follows that operator isn’t a valid

PowerShell expression—and so you get a syntax error.

A.2 POWERSHELL AND UNIX SHELLS

In this section, we’ll look at examples that compare PowerShell to the UNIX

shells—in particular the Bourne shell family (

ksh

bash

, and so on).

NOTE This section in the first edition of the book caused a lot of irate

UNIX shell users to warm up their flamethrowers. (Given that my back-

ground prior to Microsoft was mostly in

UNIX and UNIX-like systems,

POWERSHELL AND UNIX SHELLS 15

I probably would have been one of them.) The point here isn’t to say

that PowerShell is better than the

UNIX shells. Rather, it’s that they take

different approaches to solving similar problems on different systems. As

a result, this becomes something of an apples and oranges discussion.

Although inspired by the

UNIX shells, PowerShell is different from them. The most

obvious difference is that PowerShell uses objects as the basic model of interaction

instead of strings. Second, the list of built-in commands is both larger and end-user

extensible, by which I mean that users can create extensions that are loaded into the

PowerShell process.

Because the same extension mechanism is used by all commands, there is no dif-

ference between the built-in commands and user-created extension cmdlets. This

model is necessitated by and a consequence of the decision to use objects. The out-of-

process extension model used by traditional shells is impractical for an object-based

shell. Even using

XML as an intermediate representation is impractical due to the cost

of serializing and deserializing each object.

NOTE There are UNIX shells that allow end-user extensions. For exam-

ple, the Desktop Korn Shell (dtksh), part of the Common Desktop

Environment

(CDE), allows for in-process end-user extensions. This lets

it call into various

GUI libraries including the Tk part of Tcl/Tk.

Instead of doing a feature-by-feature comparison of PowerShell and the

UNIX shells,

the approach in this section is to work through a set of illustrative examples showing

how a problem can be solved in each environment. Because the examples are

designed to illustrate features in PowerShell, the corresponding

UNIX examples are

non-optimal.

A.2.1 Stopping all processes

To stop all processes that begin with the letter p on a

UNIX system, you type the fol-

lowing shell command line:

$ ps -e | grep " p" | awk '{ print $1 }' | xargs kill

The

command retrieves a list of processes and sends the output text to

grep

. The

grep

command searches the string for processes whose names begin with p. The out-

put of

grep

is, in turn, sent to the

awk

command, which selects the first column in

the input text (which is the process

ID) and then passes those to the

xargs

com-

mand. The

xargs

command executes the

kill

command for each process it receives

as input. Beyond the complexity of the number of stages that need to be executed,

this command is also fragile. The problem is that the

command behaves differ-

ently on different systems (and sometimes on different versions of the same system).

For example, the

-e

flag on

may not be present; or if the processed command isn’t

in column 1 of the output, this command-line procedure will fail.

剩余166页未读，继续阅读

grantl

粉丝: 0
资源: 2

PowerShell权威指南：比较与实践

PowerShell-6.2.1-win-x64.msi

powershell

Windows PowerShell 2.0 for xp下载

Windows PowerShell 实践指南

Windows PowerShell实战指南

Windows PowerShell入门指南

PowerShell脚本编程指南

Windows PowerShell 实用教程

初识PowerShell脚本语言

PowerShell脚本编程入门指南

初识PowerShell：入门指南

PowerShell中的并发编程技巧

利用PowerShell进行系统信息采集

powershell怎么运行powershell脚本

powershell 和 powershell ISE 的区别是什么

如何在powershell中更新到最新的powershell

powershell调用powershell脚本后关闭

powershell脚本怎么调用多个powershell脚本

powershell.exe不能执行powershell脚本

最新资源