WindowsPowerShell入门系列.doc

1. Windows Power Shell 入门系列之一：开始 原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB 几年前，脚本孩子得到了驾照，同一天，脚本爸爸带儿子去完成他的首次驾驶。就像你们可能想象到的一样，脚本孩子十分兴奋，甚至无法等待他的爸爸将车开到预定的地点。他们停好车后，脚本爸爸和脚本孩子交换了他们的座位。脚本孩子启动了汽车，认真地调整好了镜子的角度，松开了手刹，并将变速箱调整到了行进档位。接着，他停止了所有的动作。 为什么停止？就这么简单：想开车是一回事，而真的开车是完全不同的另一件事。你不能责备脚本孩子的犹豫，毕竟，他一直以来都只会骑自行车，他能骑自行车到达许多他想去的地方。既然如此，那又有什么理由改变呢？为什么要放弃一个实践证明可行的交通方式，而采用另一种新的，你未必喜欢的，况且对于你来说或许太难的方式呢？诚然，汽车相比自行车有些优势，但是代价是什么呢？ 同样的事情，正发生在在为WINDOWS系统管理工作而设计的新技术上。现在你们大家都可能听说过Windows Power Shell，微软的新命令行CONSOLE和脚本语言，或许你们很多人都下载并安装了PowerShell。(如果你还没有这么做，那么请到下载Windows PowerShell去查看更多信息) 然而，就像脚本孩子一样，也许你也到此为止了。毕竟，想用新的命令行CONSOLE和脚本语言是一回事，而实际使用这个命令行CONSOLE和脚本语言，是完全不同的另一件事。你已经使用了几年的GUI，cmd.exe，以及VBScript，你本来就可以实现几乎所有你想实现的系统管理工作。为什么还要改变呢？为什么要放弃一个实践证明可行的系统管理方式，而采用另一种新的，你未必喜欢的，况且对于你来说或许太难的方式呢？ 这些都是很好的问题和正常的疑虑。坦率地讲，我们也不能解释这些问题。但是，我们要说的是：拿到了驾照，不是说你就再也不能骑自行车了。交通方式不是唯一的：拿到小轿车的驾照不等于你就不能骑自行车、开公交车，或者骑摩托车（甚至喘着气步行）。你宁愿骑自行车？没问题！想骑自行车的时候，你就骑自行车，想开汽车的时候，你就开汽车。如果你发现骑自行车给你带来更多乐趣，那么，你就骑自行车，只在真正需要的时候才开车。 Windows PowerShell也是一样。如果你学了PowerShell，难道就意味着你不能再继续使用GUI，并且抛弃你所有的VBScript吗？当然不是！许多人都认为：PowerShell是VBScript和其他管理技术的替代品。这不正确。准确地说，PowerShell是VBScript和其他管理技术的补充。也许经过一段时间的使用，有人会觉得“喔！我喜欢PowerShell，我想我会把PowerShell用在所有任务”，没问题！祝你开心，把你的问题告诉脚本专家，让我们看看有什么能帮你的。另外一些人会觉得：“我不太肯定，我喜欢PowerShell提供的一些功能，但我已经在VBScript上面花了很多时间。我宁愿继续使用VBScript。”，那么会怎么样？同样没问题！就像俗话所说的一样：如果东西没坏，就不要去改变什么。如果VBScript工作得没有问题，那么就继续使用它。 那么为什么还要考虑Windows PowerShell？有几条理由：第一，它就像是一个驾驶执照，你可能永远用不着它，但最好还是能有一个。确实，目前看来，PowerShell可能还没有什么大不了的。PowerShell能做到的大多数系统管理任务，VBScript早就能够做到了。但另一方面，也有一些例外：比如，如果你想实现自动化管理微软Exchange Server 2007，你就必须使用Power Shell。随着时间的推移，这些“例外”可能会演变为规则：因为PowerShell会被连续地改进、加强（PowerShell 2.0正在开发），而VBScript却不会。不得不承认，你可能现在还不需要PowerShell，但很快，也许就会发生改变。因此为什么不乘现在你有时间，并且可以根据自己的时间安排进度，提前先开始学习呢？ 这个，就是这篇Windows PowerShell Manual手册的初衷：本文希望用温和且轻松的方式介绍Windows PowerShell。就像很多其他手册，我们告诉你怎么踩油门，怎么“驾驶”你的新命令行CONSOLE和新的脚本语言。其后，我们也要告诉你怎么维护你的新命令行CONSOLE以及脚本语言。并且请不必担心，除了标准内容，我们也会介绍一下一些附件和自定义的项目。我们知道你们其中一些人已经安装了Windows PowerShell，并且从那时起，就坐在一旁想：“好了，现在该干什么了？”。如果你也是这样，好，你可以停止烦恼了，你已经来到了正确的地方。 2. Windows Power Shell 入门系列之二：启动原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB 当你安装Windows PowerShell时，安装程序已经为你安装好了一个快捷方式。对于Windows XP和Windows 2003，快捷方式应该在“开始 - 所有程序 - Windows PowerShell 1.0 - Windows PowerShell”。没找到快捷方式？那么PowerShell的默认安装路径在%windir%System32WindowsPowerShellv1.0 （例如：C:WindowsSystem32WindowsPowerShellv1.0）。打开文件夹，双击PowerShell.exe。 当你启动Windows PowerShell后，会看见类似下图的一个窗口： 如果你在想“咦，这个看上去就像MS-DOS命令行窗口“，对了！PowerShell正是利用了MS-DOS的命令行SHELL。这样做至少有一个好处：因为你可能已经使用了无数次旧的命令行窗口，那么你对如何使用PowerShell已经有了一个很好的基本概念：键入命令然后按下ENTER键。例如，你知道你的IP地址吗？键入ipconfig然后按下ENTER键。 PS C:Scripts ipconfig Windows IP Configuration Ethernet adapter Local Area Connection: Media State . . . . . . . . . . . : Media disconnected Ethernet adapter Wireless Network Connection: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 7 Subnet Mask . . . . . . . . . . . : Default Gateway . . . . . . . . . : 正如上面的例子所暗示的一样，你可以在PowerShell中运行所有的命令行可执行命令。你甚至可以在PowerShell窗口中运行你的VBScript和批处理文件。你想在Windows PowerShell窗口中运行 C:ScriptsTest.vbs吗？没问题：PS C:Scripts test.vbsMicrosoft (R) Windows Script Host Version 5.6Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.This message was generated by Test.vbs.另外，在Windows PowerShell中你可以找到许多你喜欢的终端命令，比如 cd和cls，甚至UNIX命令如ls。虽然也有些不重要的小小例外，但这些命令几乎会完全按照你期望的方式运行。你想把当前目录从C:Script改变到C:Windows吗？只需要使用一条cd命令：PS C:scripts cd c:windowsPS C:WINDOWS Or, if you prefer:PS C:scripts chdir c:windowsPS C:WINDOWS一般情况下，这些终端命令都是Windows PowerShell cmdlets的“别名“。如果你愿意看一下完整的别名列表，只需要输入下面的命令，并且按下ENTER：Get-AliasPowerShell是大小写不敏感的，你也可以这样输入这个命令：get-alias甚至这样：geT-ALIaS3. Windows Power Shell 入门系列之三：停、停，等等，什么是Cmdlets?原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB 哦，对了，问得好。Cmdlets是Windows PowerShell的命令，它们有些类似命令行工具。（然而，Cmdlets只能在PowerShell里使用，没有运行PowerShell时，你是不能单独运行PowerShell的Cmdlets的）。如果没有命令行工具，Cmd.exe也不会有太大作为的，即使它有那么几个内置命令（例如cd和cls）。许多“高级“的（以及大多数有用的）任务，都是通过命令行工具完成的，比如ipconfig.exe和ping.exe。Windows PowerShell也以相似的方式工作：虽然PowerShell已经有了一些内置的命令，但大多数高级的工作，还是必须通过Cmdlets来完成。 实际上，PowerShell的命令（比如cd）没有更多的含义，它们都只是Cmdlets的别名而已，它们只是Cmdlets的“昵称“。在这个例子中，cd命令只是一个调用Set-Location这个Cmdlet的另外一种方法。想切换当前目录到C:Windows？你可以直接使用Set-Location替代cd命令：PS C:scripts Set-Location C:WindowsPS C:WINDOWS当然，Windows PowerShell中包含的Cmdlets功能远远比切换目录强大得多。举个例子来说：输入下面的命令，然后看看会发现什么：PS C:WINDOWS Get-Process你会得到下列类似的返回结果，所有正在你计算机上运行的进程信息！Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName- - - - - - - - 103 5 1296 3676 32 0.05 2964 alg 264 7 4872 10244 70 0.84 920 asghost 101 4 3080 4692 38 1.77 2124 atiptaxx 168 7 5584 6968 54 0.30 2896 BTStackServer 143 5 3712 6640 52 0.30 2776 BTTray 752 13 11048 20256 77 2.81 452 CcmExec 672 7 2796 6864 68 18.80 1184 csrss 139 6 1204 4544 38 0.70 2760 ctfmon很灵活吧？或许你还想列出C:Scripts目录下的所有文件，包括所有子文件夹中的文件，你只需要输入：Get-ChildItem C:Scripts -recurse我们所做的，只是调用了Get-ChildItem这个Cmdlet。你也许注意到了我们传递给Get-ChildItem一对参数：C:Scripts和-recurse。正如你猜到的一样，C:Scripts是我们希望列举文件的目录路径名。你也许还注意到，我们没有把目录路径名称用双引号括起来。在PowerShell中，有一条规则几乎总是成立：没有必要把参数名用引号包围起来，除非你的参数中包含空格。比如：假设你要列举在C:Documents and SettingsKen Myer目录下的所有文件。由于这个路径中含有空格，因此需要将路径名用双引号包围起来：Get-ChildItem C:Documents and SettingsKen Myer我们最初那个命令的第二个参数，-recurse，告诉Get-ChildItem递归地获取目录文件信息。这是告诉Get-ChildItem获取所有C:Scripts的子目录信息（以及子目录的子目录）。Windows PowerShell 1.0有129个Cmdlet，这些Cmdlets包括文件、文件夹管理，文本文件读写，事件日志管理，甚至可以创建COM和.NET框架的对象。 现在，一切都进行得很好，但是在坐到方向盘后面开始驾驶之前，脚本孩子并没有真正学过开车。阅读并不能替代实践。Windows PowerShell没有什么不同，你也可以阅读有关Cmdlet的相关资料，但是仅仅通过阅读，你不会得到对cmdlets的全面感受，以及它们能做什么，直到你真正坐到方向盘后面开始实际地使用Windows PowerShell。当脚本专家无法做到副驾驶位置并给予你指导时（就像“减速！看路边！不要这么猛地踩刹车！”），我们可以做第二好的选择：我们提供每一个步骤的指引，带领你使用Windows PowerShell完成一些典型的系统管理场景。如果你觉得这很有趣（为什么不呢？），你可以去我们的PowerShell虚拟实验室看一下Windows PowerShell virtual 。 提示： 这里有一个可以节约时间的小提示。当cmdlet和参数一起使用时，你可以只输入恰好可以唯一识别这个参数的字符数量。这是什么意思？比如，Get-ChildItem只有一个参数（recurse），这个参数以字符r开头。这意味着我们可以使用下面的命令格式表示-recurse参数：Get-ChildItem C:Scripts -r如果Get-ChildItem还有一个参数以字母r开头，我们假设它叫-readonly。在这个例子中，我们可以这样指定-recurse参数：Get-ChildItem C:Scripts -rec为什么需要输入-rec？很简单：我们必须键入足够的字母（3位），才能让cmdlet区分出-recurse和readonly： -recurse -readonly还是觉得打字太多了？那好，如果你用gci这个别名（不用说，gci就是Get-ChildItem的别名），你可以用下面的简短命令递归地获取C:Scripts目录的内容：gci C:Scripts -r酷吧！4. Windows Power Shell 入门系列之四：我有几个问题要问你们 原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB 是的，我们知道：你想了解另外还有哪些cmdlets，你还想了解这些cmdlets都有什么用。真实情况是：我们无法在这篇文章里解答这些问题。然而，我们可以给出一个容易接受的资源，你可以自己回答这些问题。 首先，Windows PowerShell是一个非常容易交流而且开放的技术：你只需要提出问题进行询问，PowerShell会非常高兴地告诉你所有关于它的一切，还记得Get-Alias这个cmdlet吗？它返回一个所有别名的列表。与此类似的，还有一条cmdlet：Get-Command，它返回一个所有cmdlets的列表。下面是部分Get-Command的返回信息：PS C:scripts Get-CommandCommandType Name Definition- - -Cmdlet Add-Content Add-Content -Path -Value Object.Cmdlet Add-History Add-History -InputObject -Pass.Cmdlet Add-Member Add-Member -MemberType -Name.Cmdlet Add-PSSnapin Add-PSSnapin -Name -PassThru -Ve.Cmdlet Clear-Content Clear-Content -Path -Filter Strin.Cmdlet Clear-Item Clear-Item -Path -Force -Filter .Cmdlet Clear-ItemProperty Clear-ItemProperty -Path -Name Get-Command | Format-List这样，你就能按顺序获得所有cmdlets的完整信息了：Name : Add-ContentCommandType : CmdletDefinition : Add-Content -Path -Value -PassThru -Filter -Include -Exclude -Force -Credential -Verbose -Debug -ErrorAction -ErrorVariable -OutVariable -OutBuffer -WhatIf -Confirm -Encoding Add-Content -LiteralPath -Value -PassThru -Filter -Include -Exclude -Force -Credential -Verbose -Debug -ErrorAc tion -ErrorVariable -OutVariable -OutBuffer -Wh atIf -Confirm -Encoding Path :AssemblyInfo :DLL : C:WINDOWSassemblyGAC_MSILMicrosoft.PowerShell.Commands.Management_31bf3856ad364e35Micr osoft.PowerShell.Commands.Management.dllHelpFile : Microsoft.PowerShell.Commands.Management.dll-Help.xmlParameterSets : Path, LiteralPathImplementingType : Microsoft.PowerShell.Commands.AddContentCommandVerb : AddNoun : Content我们怎么做到这个的呢？当查询返回时，Format-List是一个cmdlet，它接收信息并把它们按照list view的格式输出（list view表示每行显示一种信息，而不是把信息以列的形式显示在一个表中）。但是这个奇怪的符号“|”表示什么呢？其实，这个符号是一个管道符号，它表示：我们希望把Get-Command返回的信息通过一个内部的“管道”传递给Format-List这个cmdlet，并做进一步的处理。你说你无论如何无法理解这个东西？没关系，这也是为什么我们这篇手册专门有一章“pipelines and piping”的原因。 现在，回到我们的主题 Get-Command是很有用的：毕竟，它给你列举了所有cmdlets的信息。然而，它并没有告诉你怎么使用这些cmdlets。因此，你还需要访问PowerShell的内置帮助系统。5. Windows Power Shell 入门系列之五：PowerShell 随时提供帮助原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB PowerShell有一个非常好的特点，那就是它有一个非常全面的帮助系统，并与Shell本身紧密集成。一旦知道了cmdlet的名字，你就可以通过调用Get-Help来获取其他有关这个cmdlet的信息。Get-Help Format-List等一下，先不要输入这个命令。就像我们所提到的一样，PowerShell含有一个十分全面的帮助系统。然而，它还含有一个稍微复杂一些的帮助系统。输入Get-Help Format-List的确可以获得一些有关Format-List的附加信息。然而，这些信息主要是一个语法图和一些简单描述。如果希望获取到更多的信息，包括了例子和参数的详细描述等信息，你需要加入-full参数，就像下面一样：Get-Help Format-List -full或许，你只对例子感兴趣，那么就加入-examples参数：Get-Help Format-List -examples再等等！还是别急着输入这个命令。虽然这些帮助主题非常好，但是PowerShell的帮助引擎留下了一点小小的遗憾。例如：你用Get-Help打开了一个主题，PowerShell会显示整个主题并把光标停留在末尾。真正需要阅读的时候，你可能需要向上滚动屏幕并找到第一行。要解决这个问题（并不完全是个问题），你可以使用管道技术将Get-Help定向输出到more命令中，它允许你每次显示一个屏幕的内容：Get-Help Format-List full | more这样就好多了。虽然你还是只能向前翻页而不能向后翻页。（试一试就知道是什么意思。） 另外还有一个小问题：可能是好事也可能是坏事（更像是坏事），PowerShell的帮助系统不会处理行末的断字。例如：DETAILED DESCRIPTION The Get-Process cmdlet retrieves a process object for each process. Without parameters, Get-Process gets all of t he processes on the computer, as though you typed Get-Process *. You can also identify a particular process by pr ocess name or process ID (PID), or pass a process object through the pipeline to Get-Process. For Get-Process, the default method is by process name. For Stop-Process, the default method is by process ID.看一下在DETAILED DESCRIPTION下面的一行。你会看到这一行最后的the字并没有很好的被处理。PowerShell把字母t打印在这行的末尾，把he打印在下一行的开始位置，而不是把整个the字放在下一行。这是不是使得帮助信息更加难度呢？你或许会说是。 有没有办法处理这个问题呢？据我们所知，目前还没有。这也是为什么脚本专家们把Windows PowerShell 图形化帮助文件收集在一起的原因（另外，还有一个our VBScript to Windows PowerShell Conversion ）。这个帮助文件的内容和你在PowerShell所中能查询到的信息是一样的。所不同的是，我们已经把断字全都修复了，并且把它们全部都保存到了一个.chm文件中。这有助于阅读，并且提供了图形化的全文搜索功能。如果你还阅读了它的Readme文件，那么你甚至可以通过命令行方式访问这个帮助文件。只需要简单地输入一条命令，例如：Get-GUIHelp Format-List不用输入像-full或-examples这样的参数，使用图形化帮助文件，你总是获取到所有的相关信息。 你知道吗？你是对的，帮助系统是那么有用，它提供了你已经知道的命令的详细帮助。（例如，你想使用Get-ChildItem来列举C:Scripts下所有的文件和目录，你只是记不清应该使用那个参数来递归获取目录和文件。）但是，如果你连使用PowerShell的哪个命令来完成你的工作都不知道了呢？是否意味着你必须从头到尾来阅读一遍帮助文件呢？ 这样当然也不是不行。但更好的方法是，你也许可以去看看脚本中心的基于任务的Windows PowerShell介绍。在这里你可以找到基于任务的文章，这些文章的标题就像这样：Save Data to a Text File and Copy Files or Folders。你只需要做一件事情，那就是浏览一下这些文章，然后再在PowerShell的帮助文件中找到相关cmdlet的更详细的信息。 Note. 对，图形化帮助文件中带有“基于任务的帮助”的链接。例如，如果你正在查看Set-Content这条命令的帮助，那么你同时可以看到指向Save Data To a Text File文章的链接。 6. Windows Power Shell 入门系列之六：嗨！脚本呢？原文链接：/technet/scriptcenter/topics/winpsh/manual/start.mspx#EPB 你不会真的以为我们忘记了脚本和脚本编写技术了吧？（脚本专家可不是白叫的。）Windows PowerShell为编写和运行脚本提供了一个非常酷，非常强大的环境。然而，真正要开始在PowerShell下运行脚本，还是需要一些技巧的，至少刚开始的时候是这样。因此，本手册包含了一个单独的章节来介绍怎么在Windows PowerShell下运行脚本。 我们会在那个单独的章节中介绍大多数脚本相关的知识。如果你真的想编写PowerShell脚本，我们同样也建议你去看看我们的PowerShell scripting webcast。这里，我们只想简单说一下，PowerShell脚本可以使用任何的文本编辑器进行编辑。例如Notepad就包含了所有写脚本所需要的功能。确保将脚本文件保存在一个纯文本文件中，并且给他取一个.ps1为扩展名的文件名。这就是所有需要做的工作。 Note. 好吧，或许还有一些要坦白的：其实，你必须要写一些脚本。这也是你更加要去看看PowerShell scripting webcast的原因。 PowerShell另外还有一个很酷的功能。通篇文章我们都在说PowerShell是一个命令行CONSOLE和脚本语言。这里也是一个很好的证明：你可以从命令行窗口运行命令，也可以把命令保存在一个.ps1文件中作为一个脚本。更酷的是，这些命令都是一样的，你在在命令行中输入的命令，可以在脚本中不加改变的使用，反之亦然。 例如，下面的两行简单命令： $a = Get-ChildItem C:Scripts$a在第一行中，这个脚本用了Get-ChildItem来获取一个集合，这个集合包含了C:Scripts的所有子文件夹和文件的信息。这个集合被保存在了变量$a。第二行，就是简单地显示了一下$a变量的值。 并不那么令人激动是不是？这种想法很正常。然而，真正激动人心的是：你可以把这两个命令放在一个.ps1文件中，然后运行这个脚本，或者你也可以一条一条地在命令行提示中输入这两条命令。 不用说，将来我们还会加入更多 - 多得多 - 的有关脚本和脚本编写的更新。2008/6/17. Windows Power Shell 入门系列之七：运行你的脚本原文链接：/technet/scriptcenter/topics/winpsh/manual/run.mspx#EIGAC 生命中最激动人心的事，莫过于得到一个崭新的命令行SHELL和一个新的脚本语言。实际上，它太令人兴奋了，以至于你迫不及待地想把它拿出来炫一下，但是过度的兴奋却让你都不知道怎么打开它的包装盒。下载并安装过Windows PowerShell的人知道我们在说什么，如果你也像其他人一样，当安装程序刚刚结束你就双击一个.PS1文件（.PS1就是Windows PowerShell脚本文件的扩展名），然后坐好等待奇迹发生。 结果下面的事情发生了： 哈！脚本没有运行，而是被Notepad打开了。很有趣，不过好像跟你的想象有些不符。等一下！你可能想，我知道怎么回事了：是不是在运行Windows PowerShell Script之前必须先运行PowerShell？好，这样好像也说得通。于是，在这样的想法驱使下，你有打开了Windows PowerShell并且在命令提示下输入了.PS1文件的路径。然后按下了ENTER键并继续等待奇迹的发生： 结果却发生了下面的事情： File C:scriptstest.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see get-help about_signing for more details.At line:1 char:19+ c:scriptstest.ps1 哦好！太好了！一个新的命令行SHELL和一个新的脚本环境居然不允许你运行脚本！微软的那些专家们都在想些什么？ 别慌张，相信它，所有事情都是正常的。你只需要学习一点Windows PowerShell的小技巧。而且脚本专家正在这里教你怎么做。8. Windows Power Shell 入门系列之八：从Windows PowerShell窗口中运行你的脚本原文链接：/technet/scriptcenter/topics/winpsh/manual/run.mspx#EIGAC 现在，我们开始从Windows PowerShell中运行脚本。（这是运行Windows PowerShell脚本的主要方法。）为什么你会得到一个怪异的错误信息呢？那是因为，Windows PowerShell包含了一些安全设置，其中有一项名叫“execution policy”（脚本执行策略）。这个策略会检测PowerShell运行脚本的方式（或者是否允许执行）。默认情况下，PowerShell的执行策略是被设置为Restricted（限制执行）的，这意味着所有脚本包括你自己写的脚本，不被允许执行。 Note. 你可以用这条命令检测脚本的执行策略：Get-ExecutionPolicy 现在看来，这个策略有些太严格了。毕竟，我们要一个不能运行脚本的环境来做什么？但是没关系，如果你不喜欢默认的执行策略（你肯定不喜欢），我们可以改变它。例如，如果你希望PowerShell能够流畅运行你所有的脚本，不提出任何问题，但是对于从网络上下载的脚本，又只允许它运行那些经过可信签名的脚本。你可以用下面的命令，把执行策略设置为RemoteSigned。 Set-ExecutionPolicy RemoteSigned另外，你也可以设置执行策略为ALLSigned（所有脚本，包括你自己写的脚本，都必须被可信任的证书供应商签名）或者Unrestricted（所有脚本都可以运行，不管它们是否含有有效签名）。 Note. 不知道“给脚本签名”是什么意思？那么打开PowerShell，输入下列命令，然后按下ENTER键： Get-Help About_Signing或者，下载Windows PowerShell Graphical Help File然后阅读有关章节。 改变执行策略后，你就可以运行你的脚本了。然而还是可能发生错误。假如，你尝试切换你的当前目录到C:Scripts（就像cd C:Scripts）。C:Scripts目录下含有一个叫Test1.ps1的文件，根据一般的想法，你输入了Test.ps1然后按下了回车： Test.ps1结果你得到了这样的回答： The term test.ps1 is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.At line:1 char:7+ test.ps1 我们知道你怎么想的：我们不是已经改变了执行策略了么？是的，我们改了。但是，这与执行策略无关，这只是PowerShell处理文件路径的方法。一般情况下，如果你想运行一个脚本，你需要输入全路径。而与你的当前路径无关。就算你正在C:Scripts下工作，你仍然需要输入： C:ScriptsTest.ps1我们说“一般情况下”，是因为有几种特殊情况。举例来说，如果你想要运行当前目录下的脚本，你可以使用.符号来制定路径，就像这样： .Test.ps1虽然PowerShell不搜索你的当前路径，但是它会搜索所有PATH环境变量指定的路径。这意味着什么？意味着如果C:Scripts目录是包含在PATH变量中的，那么你就可以使用这个命令： Test.ps1这里需要小心。假设你的C:Scripts不在PATH环境变量中，而另一个目录D:Archive在PATH变量中，而且这个目录也包含一个叫Test1.ps1的文件。这时，如果你在C:Scripts目录下简单地输入Test.ps1并且按下ENTER键，想一下哪个脚本会被运行？对了，PowerShell不会运行C:ScriptsTest.ps1，而是会去运行C:ArchiveTest.ps1。仅仅因为C:Archive在PATH路径中。 Note. 这里列出了一个命令，可以获取Windows PATH环境变量的值，并且将其格式化后显示出来： $a = $env:path; $a.Split(;)9. Windows Power Shell 入门系列之九：更多关于文件路径的信息 原文链接：/technet/scriptcenter/topics/winpsh/manual/run.mspx#EIGAC 现在我们知道了，只要我们输入全路径，那么就不用担心脚本会不被允许了，对吗？对的！ 嗯，其实只能说基本对。还是有个小问题，那就是如果你的路径名中间包含了空格字符的情况。例如，你想运行C:My Scripts目录下的一个脚本。试试输入这个命令看有什么情况发生： C:My ScriptsTest.ps1当然，我们正在期待着异常的发生，不是么？你会看到这样的返回结果： The term C:My is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.At line:1 char:8+ C:My ScriptsTest.ps1这个你自己知道怎么解决，是吗？使得，就像老的Cmd.exe一样，PowerShell也不能解析含有空格的路径名。（部分的原因是由于空格被用来分隔你的命令行参数。）在Cmd.exe中，你可以通过给路径名加上双引号来解决问题。理论上你也可以在PowerShell中这么做： C:My ScriptsTest.ps1但你会得到这样的结果： C:My ScriptsTest.ps1嗯，好，再试一次，你又得到了同样的结果： C:My ScriptsTest.ps1你继续尝试 好了，够了，再继续尝试是没有意义的！无论你试多少次，PowerShell还是会给你返回同样的信息。如果你真的想运行这条字符串代表的脚本，你需要在这个字符串路径前面加上Call（调用）符号（&符号）： & C:My ScriptsTest.ps1Note. 在使用这条命令时，在&符号后面你可以留空格或者不留 总结一下，从Windows PowerShell窗口中，你应该这样运行你的脚本： 确认你已经改变了执行策略 指定完整路径，或者：1）要么使用 . 符号指定当前路径，2）要么把脚本所在的目录加入PATH环境变量 如果文件路径包含空格，使用双引号把路径引起来，并且在字符串签名加上 & 符号。是的，这就是所有你必须习惯的方法，而且你应该也愿意去习惯它们。（为了简化你的脚本生涯，我们建议你把所有脚本都放在一个文件夹里面，比如C:Scripts，然后把它加入到Windows的PATH环境变量中） Note. 我们能不能用PowerShell命令行工具加入一个目录到PATH环境变量？当然可以，有一个命令（我们不会在这个介绍性文章中解释这个命令）可以把目录C:Scripts加入到path环境变量中去。$env:path = $env:path + ;c:scripts10. Windows Power Shell 入门系列之十：“dot Sourcing”一个脚本 原文链接：/technet/scriptcenter/topics/winpsh/manual/run.mspx#EIGAC 不得不承认，迄今为止，并不是所有的消息都是好消息。你不能双击运行一个脚本，PowerShell不自动搜索你当前目录下的脚本文件，文件名中的空格可能导致问题发生，等等。因此，我们花点时间讨论一下一个非常酷的特性：dot sourcing. 假设我们有一个非常简单的VBScript脚本，就像这样： A = 5B = 10C = A + B如果你从命令行窗口运行它，它会运行得很好。然而，