我正在争论我是否应该学习PowerShell,还是坚持使用Cygwin/Perl脚本/Unix shell脚本等等。

PowerShell的好处是,没有Cygwin的队友可以更容易地使用脚本;然而,我不知道我是否真的会写那么多通用脚本,或者人们是否会使用它们。

Unix脚本功能如此强大,PowerShell是否足以让我们切换到它呢?

以下是我在PowerShell中寻找的一些具体内容(或等效内容):

grep 排序 uniq Perl (PowerShell与Perl的能力有多接近?) AWK sed File(提供文件信息的命令) 等。


我已经使用了一些PowerShell来实现脚本自动化。虽然环境看起来比Unix shell考虑得更周到,但实际上使用对象而不是文本流要笨拙得多,而且过去30年开发的许多Unix设施仍然缺失。

Cygwin仍然是我在Windows主机上选择的脚本环境。在完成任务方面,它肯定胜过其他选择。


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

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


当您将PowerShell与Cygwin/Perl/Shell组合进行比较时,请注意PowerShell仅表示该组合的“Shell”部分。

然而,您可以从PowerShell调用任何命令,就像从cmd.exe或Cygwin中调用一样。它没有重新实现指定的函数,当然也不能与Perl相比。

它“只是”一个外壳,但它使编程变得更容易,为。net世界提供了一个舒适的接口。

还要记住,PowerShell需要Windows XP、Windows Server 2003或更高版本,这可能会造成问题,具体取决于您的IT基础设施。

更新:

我不知道我的回答会引发什么样的哲学辩论。

我在这个问题的背景下发布了我的答案:将PowerShell与Cygwin、Perl和Bash进行比较。

PowerShell是一个shell,因为它在内置命令、命令行、用户函数和外部命令(.exe、.bat、.cmd)之间没有语法上的区别。只有在调用中添加名称空间或对象才能调用。net方法。

它的可编程性来源于。net框架,而不是任何特定于PowerShell“语言”的东西。

我想说,一旦Bugzilla或MediaWiki被实现为运行在web服务器上的PowerShell脚本,我相信PowerShell就是一种“脚本语言”。

在那之前,享受比较吧。


无论如何,我都不是一个非常有经验的PowerShell用户,但是我接触到的一点点PowerShell给我留下了深刻的印象。您可以将内置的cmdlet链接在一起,以完成您在Unix提示符下可以完成的任何事情,并且还有一些额外的优点,用于执行诸如导出到CSV、HTML表以及更深入的系统管理类型的作业。

如果你真的需要像sed这样的东西,总有UnixUtils或GnuWin32,你可以很容易地与PowerShell集成。

作为一个长期的Unix用户,我在习惯命令命名方案时遇到了一些麻烦,如果我了解更多的。net,我肯定会从中受益更多。

所以本质上,我认为如果windows独有的特性不构成问题,它是非常值得学习的。


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

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

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


Select-String cmdlet和-match操作符使用正则表达式。此外,您还可以直接使用. net的正则表达式支持来实现更高级的功能。

排序

sort - object更强大(比我记得*nix的sort更强大)。允许对任意表达式进行多级排序。在这里,PowerShell对底层类型的维护有所帮助;例如,DateTime属性将被排序为DateTime,而不必确保格式化为可排序的格式。

uniq

Select-Object独特

Perl (PowerShell的功能有多接近Perl ?)

就Perl领域特定支持库的广度而言:还远远不及(目前)。

对于通用编程来说,PowerShell当然更具有内聚性和一致性,也更容易扩展。文本修改的一个缺口相当于Perl的。操作符。

哗啦��

自从使用AWK以来已经足够长了(肯定是>18年了,因为后来我只使用Perl),所以不能真正评论。

赛德

(见上图)

File(提供文件信息的命令)

PowerShell的优势并不在于它可以对文件系统对象做什么(它在这里获得了全部信息,dir返回FileInfo或FolderInfo对象),而是它是整个提供者模型。

您可以将注册表、证书存储、SQL Server、Internet Explorer的RSS缓存等视为对象空间,可以通过与文件系统相同的cmdlet进行导航。


PowerShell绝对是Windows的发展方向。微软已经将其列为未来非家用产品的要求之一。因此在Exchange中有丰富的支持,在SQL Server中有支持。这个只会膨胀。

最近的一个例子是TFS PowerToys。许多TFS客户端操作都不需要每次启动tf.exe(这需要一个新的TFS服务器连接等),并且更容易进一步处理数据。以及允许广泛访问整个TFS客户端API,以比在TF.exe的任何团队资源管理器中公开的更详细的信息。


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

如果你知道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编程不值得付出努力。

我有几年在Unix下编写shell脚本的经验,但是我发现用PowerShell做任何事情都非常困难。

似乎许多函数都需要您查询Windows管理界面并发出类似sql的命令来获得所需的信息。

例如,我想编写一个脚本来从目录树中删除具有特定后缀的所有文件。在Unix下,这将是一个简单的…

find . -name \*.xyz -exec rm {} \;

在几个小时的脚本之后。FileSystemObject和WScript。Shell并发出“SELECT * FROM Win32_ShortcutFile WHERE Drive = '”& Drive & " and Path = '" & searchFolder & "'”,我最终放弃了,并解决了Windows资源管理器的搜索命令,只是手动执行。可能有一些方法可以做到我想要的,但我没有看到任何明显的东西,MSDN网站上的所有示例都是如此微不足道,以至于毫无价值。

EDIT嘿,当然,当我写这篇文章的时候,我又戳了一下,发现了我遗漏的东西:remove-item命令的-递归选项是错误的(如果你使用get-help remove-item -detailed就会显示出来)。

我一直在尝试“remove-item -filter '* .xyz' -recurse”,但它不起作用,所以我放弃了它。

事实证明你需要使用get-childitem -filter '*。Xyz ' -递归| remove-item


PowerShell功能非常强大,比Unix shell的标准内置功能更强大(但这只是因为它包含了许多通常分配给子程序的功能)。另外,考虑到你可以用任何。net语言编写小程序,包括IronPython、IronRuby、PerlNet等。或者你可以简单地从PowerShell调用你的Cygwin命令,忽略所有额外的功能,它将类似于Bash, KornShell,或任何…


作为一个从1997年到2010年专注于Windows企业开发的人,显而易见的答案是PowerShell,因为前面给出的所有好的理由(例如,它是微软企业战略的一部分;与Windows/COM/.NET集成良好;使用对象而不是文件提供了一个“更丰富的”编码模型)。出于这个原因,我在过去两年左右的时间里一直在使用和推广PowerShell,并明确地相信我是在遵循“比尔之言”。

然而,作为一个实用主义者,我不再确定PowerShell是一个很好的答案。虽然这是一款出色的Windows工具,并且为填补Windows命令行这一历史性的漏洞提供了非常必要的一步,但我们都看到微软对消费者计算的控制正在下滑,微软似乎越来越有可能面临一场大规模的战斗,以保持其操作系统对未来企业的重要性。

事实上,鉴于我发现我的工作越来越多地处于不同的环境中,我发现目前使用Bash脚本要有用得多,因为它们不仅可以在Linux、Solaris和Mac OS X上工作,而且还可以在cygwin的帮助下在Windows上工作。

因此,如果您相信操作系统的未来是商品化的,而不是垄断的,那么选择一种灵活的开发工具策略,在可行的情况下远离专有工具似乎是有意义的。然而,如果你认为你的未来被所有的雷德蒙德所主宰,那么就选择PowerShell吧。


您还可以尝试使用BashWin at在Windows上运行Bash脚本 https://github.com/skanga/BashWin。


PowerShell中的cmdlet非常好,工作可靠。因为我是一名Java/ c#开发人员,所以它们的面向对象性非常吸引我,但这并不是一个完整的集合。由于它是面向对象的,因此它错过了POSIX工具集(例如awk和sed)的许多文本流成熟度。

The best answer I've found to the dilemma of loving OO techniques and loving the maturity in the POSIX tools is to use both! One great aspect of PowerShell is that it does an excellent job piping objects to standard streams. PowerShell by default uses an object pipeline to transport its objects around. These aren't the standard streams (standard out, standard error, and standard in). When PowerShell needs to pass output to a standard process that doesn't have an object pipeline, it first converts the objects to a text stream. Since it does this so well, PowerShell makes an excellent place to host POSIX tools!

最好的POSIX工具集是GnuWin32。它确实需要超过5秒钟的时间来安装,但这是值得的,据我所知,它不会修改你的系统(注册表,c:\windows\*文件夹等),除了将文件复制到你指定的目录。这是非常好的,因为如果您将工具放在共享目录中,许多人可以同时访问它们。

GnuWin32安装说明

下载并执行exe(它来自SourceForge网站)指向一个合适的目录(我将使用C:\bin)。它会在那里创建一个GetGnuWin32目录,你将在其中运行download.bat,然后是install.bat(不带参数),之后会有一个C:\bin\GetGnuWin32\gnuwin32\bin目录,这是Windows机器上曾经存在过的最有用的文件夹。将该目录添加到路径中,就可以开始了。


在几行中,Cygwin和PowerShell是不同的工具,但是如果你安装了Cygwin,你可以在PowerShell会话中运行Cygwin可执行文件。我已经习惯了PowerShell,现在我不再使用grep, sort, awk等。在PowerShell中有很多内置的替代方案,如果没有,您可以在那里找到cmdlet。

我发现自己使用的主要工具是ssh.exe,但是在PowerShell会话中。

效果很好。


为什么不两者都用呢?在Cygwin中调用PowerShell脚本,就像其他解释性脚本(如Perl)一样。

为此,我编写了https://bitbucket.org/jbianchi/powershell,以便Bash包装器在Cygwin中调用powershell.exe。它可以用作PowerShell .exe .ps1脚本的第一行shebang(因为PowerShell也使用“#”作为注释)。参见https://bitbucket.org/jbianchi/powershell/wiki/Home获取示例


我直到最近才开始认真地接触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用户一样)进行交互时。


TL;DR——我不讨厌Windows或PowerShell。我在Windows或PowerShell上什么都做不了。


我个人仍然觉得PowerShell充其量只能说是平淡无奇。

tab completion of directory paths do not compound, requiring the user to enter a path separator after every name completion. I still feel like Windows doesn't even have the concept of a path or of what a path is, with no accessible user home indicator ~/ short of some @environment://somejibberish/%user_home% NTFS is still a mess and seemingly always will be. Good luck navigating. cmd-esque interface, The dinosaur cmd.exe is still visible in PowerShell, Edit → Mark still being the only way to copy information, and copying only in the form of rectangular blocks of visible terminal space. and Edit → Mark still being the only way to paste strings into the terminal. Painting it blue doesn't make it any more attractive. I don't mind Microsoft developers having a taste in color though. Windows always opens at top left corner of screen. For somebody who uses vertical task bars this is incredibly annoying, especially considering that the Windows task bar will cover the only corner of the window that gives access to copy/paste functionality.

关于Windows包含的工具,我不能说太多。由于有一整套开源的、免费授权的CLI工具,而且PowerShell附带了这些工具,据我所知,没有一个是完全令人失望的。

PowerShell的wget的参数似乎与GNU的wget无法相比。谢谢,希望之光便携无用。 PowerShell POSIX与bash不兼容,特别是&&运算符没有被处理,使得最简单的条件命令也不能跟在后面。

我不了解人类;我试过了,真的;我仍然试着给它一个机会,希望下次我打开它的时候,它不会那么无用。我不能在PowerShell中做任何事情,我也几乎不能在真正的项目中将GNU工具引入Windows。

MySysGit为我提供了带有几个GNU工具的陈旧cmd.exe提示符,它仍然非常令人印象深刻,但最终路径补全工作了。Git命令将在Git Bash中运行。

Mintty for MySysGit为MySysGit的环境提供了Cygwin界面,使复制和粘贴一个东西(选择复制(鼠标),Shift+Ins粘贴,多么现代…)然而,像git push这样的东西在Mintty中被破坏了。

我并不是要抱怨,但我仍然看到Windows上命令行可用性的巨大问题,即使使用了Cygwin这样的工具。


注:仅仅因为在PowerShell中可以做一些事情,并不意味着它就可用。可用性比能力更重要,这也是我作为消费者在使用产品时所关注的问题。


由于我最近的实验让我深入了解了PowerShell和。net调用,我必须说PowerShell可以取代Cygwin和Unix shell。

我对Perl不太确定,但由于PowerShell和Perl作为编程语言都是图灵完备的,所以我认为也可以取代Perl。

PowerShell优于Cygwin和*nix下的普通Bash的一点是,它能够执行沙盒DLL调用,通过直接API调用、WMI方法甚至COM对象操纵操作系统。如何通过代码启动Internet Explorer,然后对其显示的文档做任何想做的事情,有效地模拟Web服务器的后端?

如何从SQL服务器和其他数据提供者收集数据,解析它们并导出为CSV、邮件消息、文本以及任何现有和不存在的文件格式?(当然,使用适当的技能从接收到的数据中创建有效的文件,但CSV是现成的)。

通过签名的cmdlet和脚本,可以获得额外的安全性, 组策略和执行策略有助于防止恶意代码在您的系统上运行,即使您以管理员身份运行它们。

关于执行什么命令——Richard的回答列出了它们以及PowerShell已经能够模拟它们的功能。

关于PowerShell是否强大到可以保证切换-这更多的是个人偏好的问题,尽管越来越多的Windows服务提供PowerShell cmdlet来控制它们,不使用这些服务的PowerShell被认为是一个障碍。(Hyper-V服务器是主要的这种服务,它还提供了使用PowerShell cmdlet比使用GUI做更多事情的能力!)

也许这个答案晚了五年,但是,如果有人在Windows上执行管理任务或各种东西的一般脚本,他们肯定应该尝试利用PowerShell来达到他们的目的。


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

grep = "Select-String -Pattern"

sort = " sort - object "

uniq = "Get-Unique"

file = "Get-Item"

cat = "Get-Content"

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