PowerShell in Action -- OK wait, what the heck is PowerShell?
其实做为翻译者，我肯定是愿意根据自己的喜好选择文章，但完全针对自己的喜好对国内的PowerShell社区建设帮助不会太大，因为，Windows PowerShell在国内的普及程度实在是太低了。。。打开百度搜一下PowerShell，找不到几篇与其相关的博客，其他的搜索结果也大都是一两年前的老文章，这说明什么，说明国内PowerShell的用户少，高级用户更少。所以我觉得，一些基础介绍性质的文章也会是很必要的，毕竟，在夸它多牛多强多直观前总要先让人知道，这玩意儿到底是嘛？
So, what the heck is PowerShell?
以下内容节选自Windows PowerShell in Action (第二版）
WHAT IS POWERSHELL?
什么是PowerShell，为什么我们要开发它？PowerShell是微软新一代的命令行和脚本编程环境，我们开发这个项目只有一个目的，那就是为微软的Windows操作系统提供最好的Shell，最好的脚本执行环境。虽然说我们大量借鉴了现有命令行和脚本语言的特色，但PowerShell的language和runtime都是完全重新设计的，这就是为了让它成为最适合Windows操作系统的，最优化的命令行环境。
Windows的命令行（cmd.exe）一直以来都是被人诟病的对象，尤其是对大多数高级用户来说，它简直没有办法和Linux/Unix bash的灵活强大相比拟。这个结果是有一定历史原因的，微软早期一直把普通用户作为操作系统面向的重点对象，这些普通用户一般没有特别的技术知识，也不是对计算机的运行机制有太多的兴趣。因此，微软把绝大部分的资源和努力放在了对图形用户界面的改进和创新上，而不是为数量少得多的计算机专业人员创造一个他们更感兴趣的命令行环境。不能否认，这是微软一个成功的商业策略，但遗憾的是，它也的确忽视了一个重要群体的需求。
PowerShell的诞生是各种商业压力和实际需求共同促成的，我会在接下来的几个章节里简单的介绍它们。现在呢，我们还是先明确一下Shell和脚本的定义。
Shells，command lines, and scripting languages
我们一直称PowerShell是一个命令行shell，你可能要问了，什么是shell？它与命令解释器(command interpreter)又有什么区别呢？脚本语言又是什么呢？如果一个shell提供了用户编写脚本的功能，那么是不是可以说那就是个脚本语言呢？别着急，我会回答你的问题的，让我们就从shell开始吧。
Shell是一个比较不容易定义的名词，尤其是在微软，因为几乎所有的微软产品都有被叫做shell的组件。Windows Explorer（windows资源管理器）是一个shell，Visual Studio有个被叫做shell的组件，甚至Xbox里也有被叫做shell的东西。
从历史上来说，shell这个名词指的坐落在操作系统核心功能之上一种软件。这里说的核心功能指的是操作系统的kernel(shell...kernel...明白没？)。shell这种软件就是负责将操作系统的核心功能暴露出来，供用户使用。Windows Explorer被叫做shell很恰当，因为它做的就是为Windows操作系统提供用户接口，让用户通过它去使用这个系统。但对于我们，那种”用户敲一个命令获得一个相应“的传统命令行式的交互方式更让我们感兴趣。换句话说，一个shell就是一个命令行解释器，反之亦然。
Scripting languages vs. shells
如果这么说，那么什么是脚本编程呢？脚本语言又跟shell有什么不一样呢？在某种程度上，没有什么差别，很多脚本语言都具备一个REPL模式（Read-Eveluate-Print loop），在这个模式下，这些脚本语言可以接受用户的命令，执行这些命令，然后返回结果。虽然不是每一个脚本语言都有交互模式，但很多是有的。那么一个有REPL的脚本语言和命令行shell有不同之处吗？有，不同之处主要在于用户体验。一个合格的命令行shell也应该是一个合格的用户接口，因此，一个命令行应该提供很多功能来让用户有方便和可定制的使用体验。这些提高用户体验的功能包括”别名（alias -- 能够为一些不好记的命令起简单的别名）“，”通配符匹配（这样用户就不用总是要输入完整的命令或名字）“，以及”通过简单操作启动其他程序“的能力（而不用调用一个函数什么的）。最后，命令行shell还应该提供检查，编辑，和重新执行之前输入的命令的机制，这个机制就叫command history（命令历史）。
好吧，如果说一个有REPL功能的脚本语言可以成为shell（显然我们可以让一个REPL具备友好的用户接口功能），那么shell能够成为脚本语言吗？答案毫无疑问是肯定的，一个最直接的例子就是Unix的shell language，我们很清楚的看到它演变的越来越强大，我们完全可以使用现代的shell langauge，比如bash和zsh，写出大量的应用。脚本语言在其本质上有shell language所不及的一个优势，那就是它们提供了一种叫“模块”（module）的机制，允许用户把脚本分割成一些组件，这样在使用这些脚本语言构建较大的项目时就会容易很多。还有，脚本语言一般来说都会提供更好的调试功能，并且脚本语言的runtime在实现时也都更多的考虑怎么让脚本代码更高效的运行（比如编译成本地代码），因此使用这些脚本语言写的代码一般会比使用对应shell language的代码运行的更快。最后，脚本语言的语法也都更加面向应用程序编写，而不是交互式的发出命令。
事实上，shell language和脚本语言之间并不存在一个很明确的分界线。一些脚本语言里很好的特性可能在一个命令行shell中反倒不合适，会给用户很糟的使用体验。反过来也一样，一些交互式shell里很好的特性也可能会妨碍脚本编程。PowerShell的一个目标就是成为一个好的交互式命令行shell，同时也是一个好的脚本语言，所以如何在用户体验和脚本编程之间做取舍权衡就成了在language design时一个最重要的挑战。
Why a new shell? Why now?
早在10年前，微软做过一项调查，来找出在哪些方面上可以进一步提升其server的竞争力。Server Management，尤其是基于命令行的Windows系统管理成为了一个关键的改进点。有些人可能会觉得这是显而易见的，但是重点在于，我们确实开始重视这个问题了。当调查团队把Windows系统下命令行管理功能和Unix系统比较时，Windows明显处于下风，而且这也的的确确是让我们的客户很头疼的问题。
Windows命令行的积弱是有一些历史原因的。首先，正如之前说过的，在命令行方面给予的资源和努力很有限。普通的用户不会在乎命令行，所以它没有被重视。第二，开发GUIs意味着你需要通过APIs访问你要管理的对象，而APIs几乎都是以二进制的形式存在（尤其是在Windows上），二进制的接口是不适合命令行模式的。
还有一个重要的原因，那就是行业的发展和对计算能力更高的要求带来的需求。对计算能力需求的增高和PC硬件价格的下降，使得Windows开始从办公桌向企业级的数据中心转移。数据中心里有大量的服务器需要管理，但是图形化界面的管理模式却不再适用于这个环境了，所有的这些因素都愈加清晰的指明一个问题：微软不能再忽视命令行了。
The last mile problem
为什么你应该关注命令行式管理和自动化呢？因为它帮助你解决IT专业人员眼中的”last mile problem“。”最后一英里问题“是一个起源于电信通讯行业的经典问题：电信工业可以很容易的把其基础设施建设的成本分摊到所有用户身上，因为一旦基础施舍建设完毕，所有用户都会用到它的服务。但是最终把服务接到用户家中的这最后一英里的建设成本却无法以同样的方式被分摊，因为它仅仅服务于一个具体的地点，而服务于不同特定地点的成本却有很大的差别，比如说，针对一个乡村农户的最后一英里成本就一定比城市里一家居民的成本大得多。
在IT行业，最后一英里问题就是搞清楚对于每一个IT结构，如何管理才能最经济有效。即使是一个小的IT环境也有多种多样的设备和应用程序。解决这个问题的一个方法是咨询：IT制造商提供咨询师来为每一个客户构建最后一英里的解决方案。这种方法会带来重复性的开销和可扩展问题（当然对于制造商来说是好事）。一个更好的解决方法是允许用户自己去解决他们自己的最后一英里问题 -- 我们通过提供一些工具来使得用户构建自己的解决方案（自动化-automation）。构建整个“基础设施”使用的那些工具（APIs）是不能胜任这个需求的 -- 那些工具太过于底层，使用的门槛太高了。我们需要的是一些更高层的工具（command），更抽象更容易理解使用的工具。这就是PowerShell所要完成的 -- 它在更高层面的抽象允许我们更快更容易的把一个IT环境里的点滴连接起来。这就是我们为什么需要PowerShell -- 因为我们需要这样一个能胜任分布式环境中面向对象的命令行自动化工具。
<To be continued>
有很多文章介绍PowerShell中一些重要而基本的元素包括其命令行（PowerShell中称为cmdlet），管道，C#语法支持，COM对象调用，我就不再专门的翻译类似的文章了，这里给出一篇相关的中文blog链接，里面简单介绍了这些基本元素，值得一提的是文章一开始的一个使用Excel COM object的例子，非常吸引人，作为开篇代码示范再合适不过：http://www.cnblogs.com/grapeot/archive/2010/02/22/1670822.html
这里还推荐PowerShell的inventor，Jeffery Snover的一篇blog -- Monad Manifesto，大致介绍了PowerShell从一开始到现在的过程，令人难以置信的是，一开始做的planning和goal setting，居然和项目的发展贴合的如此之紧，更让我想象起来觉得不可思议的是，他们居然把设想做成了一款如此成功的产品：几近完美的结合了.Net和COM，灵活的Cmdlet编写方式，新颖的实现了管道的概念 -- 管道连接命令在同一线程里执行，对象在管道中传递 ...
PowerShell是一款伟大的产品。
