如果你喜欢shell脚本，你一定会爱上PowerShell!

从微软命令Shell (Ars Technica)的导游之旅开始。

如果你喜欢shell脚本，你一定会爱上PowerShell!

从微软命令Shell (Ars Technica)的导游之旅开始。

工具只是工具。 他们要么帮忙，要么不帮忙。 你需要帮助或者不需要。

如果你知道Unix，并且这些工具能在Windows上做你需要它们做的事情——那么你是一个快乐的家伙，没有必要学习PowerShell(除非你想探索)。

我最初的意图是在Windows中包含一组Unix工具，然后就完成它(我们团队中的许多人都有深厚的Unix背景，并且对该社区非常尊重)。

我发现这并没有多大帮助。原因是AWK/grep/sed不能对抗COM、WMI、ADSI、注册表、证书存储等等。

换句话说，UNIX是一个围绕文本文件自调的完整生态系统。因此，文本处理工具是有效的管理工具。Windows是一个完全不同的生态系统，围绕api和对象进行自我调整。这就是我们发明PowerShell的原因。

我想你会发现，在很多情况下，文本处理并不能在Windows上得到你想要的东西。这时，您将想要选择PowerShell。注意-这不是一个全有或全无的交易。在PowerShell中，您可以调用Unix工具(并使用它们的文本处理或PowerShell的文本处理)。你也可以从Unix工具中调用PowerShell来获取文本。

再次强调，这里没有宗教信仰，我们的重点是为您提供成功所需的工具。这就是为什么我们如此热衷于反馈。让我们知道我们在工作中哪里失败了，或者你在哪里没有你需要的工具，我们会把它列在清单上，然后开始处理。

坦率地说，我们正在从30年的坑里挖出来，所以还需要一段时间。也就是说，如果你拿起Windows Server 2008 /R2的测试版和/或我们的服务器产品的测试版，我想你会惊讶地发现这个漏洞很快就被填满了。

至于使用情况，到目前为止我们已经有350万次下载量。这并不包括在Windows Server 2008中使用它的人，因为它是作为可选组件包含的，不需要下载。

V2将在所有版本的Windows中发布。它将在默认情况下开启所有版本，除了服务器核心，在那里它是一个可选组件。在Windows 7/Windows Server 2008 R2发布后不久，我们将在所有平台(Windows XP及以上)上发布V2。换句话说，您在学习方面的投资将适用于非常多的机器/环境。

最后一个评论。如果/当你开始学习PowerShell，我想你会很开心的。大部分设计都受到我们Unix背景的严重影响，所以虽然我们非常不同，但你会很快学会(在你不再抱怨它不是Unix之后:-))。

我们知道人们用于学习的预算非常有限——这就是为什么我们非常重视一致性。你会学到一些东西，然后你会一遍又一遍地使用它。

实验!享受吧!参与!

这里有很多很棒的答案，这是我的看法。PowerShell是准备好了，如果你是…例子:

grep = "Select-String -Pattern"

sort = " sort - object "

uniq = "Get-Unique"

file = "Get-Item"

cat = "Get-Content"

Perl/AWK/Sed不是命令，而是实用程序，因此很难比较，但在PowerShell中几乎可以做所有事情。

我还没有看到PowerShell真正流行起来，至少现在还没有。因此，除非团队中的其他人已经知道它，否则学习它可能不值得。

对于您的困境，您最好使用其他人可以支持的脚本语言，如您提到的Perl或Ruby或Python。

我认为这在很大程度上取决于你需要做什么。就我个人而言，我一直在为自己的个人脚本使用Python，但我知道当我开始编写一些东西时，我永远无法将其传递下去——所以我尽量不做任何太有革命性的事情。

我直到最近才开始认真地接触PowerShell。尽管在过去的7年里，我一直在一个几乎完全基于Windows的环境中工作，但我有Unix背景，我发现自己一直在努力将我在Windows上的交互体验“Unix化”。至少可以说，这令人沮丧。

将PowerShell与Bash、tcsh或zsh这样的东西进行比较是公平的，因为grep、sed、awk、find等实用程序严格来说都不是shell的一部分;然而，它们将永远是任何Unix环境的一部分。也就是说，像Select-String这样的PowerShell命令具有与grep非常相似的功能，并且被捆绑为PowerShell的核心模块…所以界限可能有点模糊。

我认为最关键的是文化，而事实上，各自的工具集将体现各自的文化:

Unix is a file-based, (in general, non Unicode) text-based culture. Configuration files are almost exclusively text files. Windows, on the other hand has always been far more structured in respect of configuration formats--configurations are generally kept in proprietary databases (e.g., the Windows registry) which require specialised tools for their management. The Unix administrative (and, for many years, development) interface has traditionally been the command line and the virtual terminal. Windows started off as a GUI and administrative functions have only recently started moving away from being exclusively GUI-based. We can expect the Unix experience on the command line to be a richer, more mature one given the significant lead it has on PowerShell, and my experience matches this. On this, in my experience: The Unix administrative experience is geared towards making things easy to do in a minimal amount of key strokes; this is probably as a result of the historical situation of having to administer a server over a slow 9600 baud dial-up connection. Now PowerShell does have aliases which go a long way to getting around the rather verbose Verb-Noun standard, but getting to know those aliases is a bit of a pain (anyone know of something better than: alias | where {$_.ResolvedCommandName -eq "<command>"}?). An example of the rich way in which history can be manipulated: iptables commands are often long-winded and repeating them with slight differences would be a pain if it weren't for just one of many neat features of history manipulation built into Bash, so inserting an iptables rule like the following: iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT a second time for another camera ("camera-2"), is just a case of issuing: !!:s/-1-/-2-/:s/50/51 which means "perform the previous command, but substitute -1- with -2- and 50 with 51. The Unix experience is optimised for touch-typists; one can pretty much do everything without leaving the "home" position. For example, in Bash, using the Emacs key bindings (yes, Bash also supports vi bindings), cycling through the history is done using Ctrl-P and Ctrl-N whilst moving to the start and end of a line is done using Ctrl-A and Ctrl-E respectively ... and it definitely doesn't end there. Try even the simplest of navigation in the PowerShell console without moving from the home position and you're in trouble. Simple things like versatile paging (a la less) on Unix don't seem to be available out-of-the-box in PowerShell which is a little frustrating, and a rich editor experience doesn't exist either. Of course, one can always download third-party tools that will fill those gaps, but it sure would be nice if these things were just "there" like they are on pretty much any flavour of Unix. The Windows culture, at least in terms of system API's is largely driven by the supporting frameworks, viz., COM and .NET, both of-which are highly structured and object-based. On the other hand, access to Unix APIs has traditionally been through a file interface (/dev and /proc) or (non-object-oriented) C-style library calls. It's no surprise then that the scripting experiences match their respective OS paradigms. PowerShell is by nature structured (everything is an object) and Bash-and-friends file-based. The structured API which is at the disposal of a PowerShell programmer is vast (essentially matching the vastness of the existing set of standard COM and .NET interfaces).

简而言之，尽管PowerShell的脚本功能可以说比Bash更强大(特别是当您考虑到. net BCL的可用性时)，但交互体验明显较弱，特别是如果您从完全由键盘驱动、基于控制台的角度(就像许多unix用户一样)进行交互时。