我正在讨论我应该学习PowerShell，还是只使用cygwin/perl脚本/unix shell脚本等。
PowerShell的好处是，没有cygwin的队友可以更容易地使用这些脚本；但是，我不知道我是否真的要写那么多通用脚本，或者人们是否会使用它们。
Unix脚本是如此强大，PowerShell是否足够接近以保证切换？
以下是我将在PowerShell中查找的一些特定内容(或等效内容)：
- 格雷普
- 分类
- UNIQ
- Perl(PowerShell与Perl的功能有多接近？)
- AWK
- 塞德
- 文件(提供文件信息的命令)
- 等。
- 我不会这么说，我对PowerShell感兴趣，找到了这个页面，现在我知道了ps和我习惯的shell脚本之间的一般区别。
- 这篇文章突然从一个HN链接提交的灰烬中冒了出来。伟大的工作。而对于@bobby来说，这样做不具有建设性。
- 如果有人不能问一个工具如何复制另一个工具的功能，那么S.O.就不能回答工具比较问题。这是为了避免争议而精心设计的，但由于看起来像是一个Unix与Windows的问题，我们粗心地认为这是"有争议的"。它得到了一个事实的、客观的答案，并对Unix脚本在Windows上的帮助有了进一步的事实洞察。
- 为什么又关闭了？有人请编辑标题说"Windows平台上的PowerShell与Unix shell"，以避免巨魔将其视为"Windows与Unix"，事实并非如此。这是一个非常有建设性的问题——投票决定重新开放。
- @X0n标题已更改！
- 我同意其他评论者的观点，他们认为这是一个有效的问题，并给出了一些有用的(非常流行的)答案。
- 就我个人而言，我认为标题应该改为：PowerShell是否准备好取代我在Windows上的cygwin shell？在我看来，这才是真正的问题——它不是真正的Unix与Windows的事情，也不是Unix工具与PowerShell的事情。最后，真正的问题是PowerShell是否已经准备好替代Windows上现有的Linux/Unix工具。当然，杰弗里下面的评论指出，这在任何情况下都不是非此即彼的事情！
- 正如所写(尤其是编辑过的问题)，这是一个程序员通常使用的软件工具，它似乎是一个实用的、可回答的问题。
- 操作人员正在用工具混合外壳。PowerShell有其用途。但是GNU是一个将Unix产品免费提供给其他操作系统(包括Windows)的项目。op给出的列表中的每一件事情都在Windows中有一个GNU实现。可从gnuwin32或单个站点访问。Windows BAT并不是无用的，它有重定向、管道和条件。
- Cygwin被WSL(以及之前的MSY)废弃。Perl在Windows上也一直是本机可用的。
工具只是工具。他们帮忙，否则就不帮忙。你需要帮助还是不需要。
如果您知道Unix和这些工具在Windows上做您需要它们做的事情，那么您是一个快乐的人，不需要学习PowerShell(除非您想探索)。
我最初的目的是在Windows中包含一组Unix工具，并用它来完成(团队中的很多人都有深厚的Unix背景和对社区的良好尊重。)我发现这并没有起到多大的作用。原因是awk/grep/sed不适用于com、wmi、adsi、注册表、cert store等。换句话说，unix是一个完整的生态系统，可以根据文本文件进行自我调优。因此，文本处理工具是有效的管理工具。Windows是一个完全不同的生态系统，围绕API和对象进行自我调优。这就是我们发明PowerShell的原因。
我想你会发现，在很多情况下，文本处理无法满足你在Windows上的需求。此时，您将需要使用PowerShell。注意-这不是一个完全或完全的交易。在PowerShell中，您可以调用Unix工具(并使用它们的文本处理或PowerShell的文本处理)。您还可以从UNIX工具调用PowerShell并获取文本。
再说一遍——这里没有宗教信仰——我们的重点是为你提供成功所需的工具。这就是为什么我们如此热衷于反馈。让我们知道我们在工作中遇到了什么困难，或者你没有你需要的工具，我们会把它列在清单上，然后开始做。老实说，我们正在挖一个30年的坑，所以要花一段时间。也就是说，如果你选择WindowsServer2008/R2的测试版和/或我们的服务器产品的测试版，我想你会对这个漏洞被填补的速度感到震惊。
关于使用情况，我们迄今为止下载量超过350万次。这不包括WindowsServer2008中使用它的人，因为它是作为可选组件包含的，不需要下载。V2将在所有版本的Windows中发布。默认情况下，除了作为可选组件的服务器核心外，所有版本都将启用它。Windows7/WindowsServer2008 R2发布后不久，我们将在所有平台XP及更高版本上提供V2。换句话说，你在学习上的投资将适用于大量的机器/环境。
最后一条评论。如果你开始学习PowerShell，我想你会很高兴的。大部分设计都受到我们的Unix背景的严重影响，因此，尽管我们有很大的不同，但您将很快地了解到它(在您克服了对它不是Unix的指责之后)：-)。我们知道人们在学习上的预算非常有限——这就是为什么我们在一致性方面是超级核心的原因。你会学到一些东西，然后你会一次又一次地使用它。
实验！享受！订婚！
- 谢谢你的回答。我想我要继续学习PowerShell。从我目前看到的情况来看，它看起来很强大，我可以在工作中用它编写更有用的脚本。
- 您可能希望从PowerShell v2的CTP3开始。它非常稳定，我们已经添加了一些很棒的东西。当你遇到问题时——在这里问他们——它将产生一个很好的可搜索知识体系。
- 我将第一次使用PowerShell。实际上，我从微软的设计师、开发人员等那里读到了一些很有前途的东西，这些东西让我不被所有微软的恶言所困扰。我喜欢"在你不再指责它不是Unix之后"的微笑。我真的看到了微软的一个趋势，它更加关注人们的需求，从整体上来说，我很高兴听到这也是PowerShell的一个动机。我很乐意评估一下这在我的工具箱里是如何适用的。
- @杰弗里：有没有机会有一个更好的Windows终端？PowerShell是一种功能强大的脚本语言，但它在cmd.exe中运行的事实使它在交互模式下更加方便。
- @sumek，@jeffrey，完全是一个更好的Windows终端，这是所有开发人员，管理员想要的，为什么不使用Unix工具呢？你是在告诉我们，使用类似于Unix的系统的纯文本文件思想，你真的无法使它工作得非常好、快速和可靠吗？请原谅我的无知，即您不能添加Windows终端二进制文件来访问对象和其他配置，并删除cmd.exe？
- 一个很好的答案，但是我在PowerShell上遇到了一个令人讨厌的小惊喜。不支持多会话历史记录！唯一一次被提到的是开发期间的非工作黑客。
- 这个"不具有建设性"的问题产生了我对整个"在Unix上，一切都是一个文件"这句咒语的最好理解，以及为什么Windows是不同的。也许StackOverflow在结束非建设性讨论时会更好？
- @苏梅克-试试看，我已经用了几个星期了，很甜：hanselman.com/blog/&hellip；
- @基思希尔，看看杰弗斯诺弗的历史，他在2012年7月13日就得到了129个关于这个问题的事件(赞成票)，但只有20个是有价值的。怎么回事？我在旗上写了同样的评论，但被拒绝了。
- @切尔涅维克虽然讨论带来了大量的见解(可能不仅仅是建设性的、无法回答的问题)，但这是一个问答网站。仅仅因为它是一个非常流行的问答网站并不意味着它应该经历这样的范围蔓延。当然，使用问答方式，你很可能无法获取所有的人类知识，但这并不能改变问答的现状。
- 注意：PowerShell不喜欢通过管道传输二进制数据。因此，当您调用可信的Unix工具时，请小心，不要直接在PowerShell中执行tar -c . | gzip > package.tar.gz之类的操作，否则您将遭受损失。参见brianreiter.org/2010/01/29/&hellip；
- 我们应该如何提供这种反馈？
- @Interarticle-这是PowerShell的已知行为。它默认将输出编码为UTF-16。通过将-encoding ascii添加到命令行很容易解决这个问题。这与必须为ftp指定二进制模式没有什么不同。
- @艾瑞克-谢谢。我记得有一次在TechNet上问过这个问题，微软工程师告诉我使用命令…不过那是几年前的事了。
- @更好的是，埃多克斯。
grep
Select-StringCmdlet和-match运算符使用regex。此外，您还可以直接利用.NET对regex的支持来实现更高级的功能。
sort
Sort-Object比nix的sort更强大。允许对任意表达式进行多级排序。在这里，PowerShell对底层类型的维护很有帮助；例如，DateTime属性将被排序为DateTime属性，而不必确保格式化为可排序格式。
uniq
Select-Object -Unique
Perl (how close does PowerShell come to Perl capabilities?)
就Perl对特定于域的支持库的广度而言：还没有关闭的地方。
对于一般编程来说，PowerShell肯定更具凝聚力和一致性，并且更易于扩展。文本挖掘的一个缺口相当于Perl的..操作符。
AWK
自从使用awk以来已经足够长了(必须大于18年，因为后来我才使用perl)，所以不能真正发表评论。
sed
[见上文]
file (the command that gives file information)
PowerShell在这里的优势不在于它可以对文件系统对象做什么(它在这里得到完整的信息，dir返回FileInfo或FolderInfo对象，这是整个提供程序模型)。
您可以将注册表、证书存储区、SQL Server、Internet Explorer的RSS缓存等视为可由与文件系统相同的Cmdlet导航的对象空间。
在Windows上，PowerShell绝对是前进的一步。微软已经将其作为未来非家用产品需求的一部分。因此，在Exchange中支持丰富，在SQL Server中支持丰富。这只会扩大。
最近的一个例子是TFS PowerToys。许多TFS客户机操作在每次都不必启动tf.exe(这需要一个新的TFS服务器连接等)的情况下完成，并且在进一步处理数据时特别容易。以及允许对整个TFS客户机API进行更详细的访问，而不是在tf.exe的任一团队资源管理器中公开。
- 问题是，提供程序模型之所以有趣，仅仅是因为操作系统不使用文本作为其通用配置介质，所以您需要这些提供程序。在Unix中，大多数语言都有API来触摸PAM、主机和软件包，但最终文本会一直存在。
- 文本并不是所有内容的最佳格式(从数据库和光栅图像开始)。但我认为我们可以同意不同意，而不是开放式的战争。
- PowerShell可以使用.NET框架中的任何对象，这与Perl的域功能不匹配吗？另外，如果您想要重新可用性，还可以用C等语言编写Cmdlet。
- 逐点比较。很好。这应该是公认的答案。PowerShell的优势在于它的.NET基础，以及通过编写新的Cmdlet甚至调用类库来扩展系统的容易程度。
作为一个从1997年到2010年专注于Windows企业发展的人，显而易见的答案是PowerShell，原因是之前给出的所有好的理由(例如，它是Microsoft企业战略的一部分；它与Windows/com/.net很好地集成；使用对象而不是文件提供了"更丰富"的编码模型)。出于这个原因，在过去两年左右的时间里，我一直在使用和推广PowerShell，我坚信我遵循的是"比尔的话"。
然而，作为一个实用主义者，我不再确定PowerShell是否是一个很好的答案。虽然它是一个优秀的Windows工具，为填补Windows命令行这一历史性漏洞提供了非常必要的一步，正如我们都看到的，微软在消费者计算上的失利，似乎越来越有可能，微软将其操作系统作为未来企业的重要组成部分，面临着一场巨大的战斗。
事实上，由于我发现我的工作越来越多地在异构环境中进行，我发现现在使用bash脚本更有用，因为它们不仅可以在Linux、Solaris和Mac OS X上工作，而且还可以在Windows上使用cygwin。
因此，如果你相信操作系统的未来是商品化的，而不是垄断的，那么选择一种敏捷开发工具策略似乎是有意义的，它在可行的情况下远离专有工具。然而，如果你看到你的未来被雷蒙德所控制，那就去买PowerShell吧。
- Unix脚本在Cygwin Windows上运行是否完美无误？
- @Pacerier我已经使用Cygwin和Mingw 12年了，几乎没有什么问题。重要的是，如果某些东西不起作用，它总是有可能回到Windows工具或其他任何东西上——进程的启动方式与任何其他shell启动它们的方式相同。
- 好吧，你的答案是2011年。今天，PowerShell也在Linux上运行。而且——我个人的看法——巴什太古板了。语法很糟糕，我宁愿使用不同的脚本语言。现在，在大多数Linux发行版上，Python都是标准的，我看不出有任何理由将bash用于脚本。我建议您再次查看PowerShell，因为自2011年以来发生了很多事情。
- 链接给那些对Linux上的PowerShell感兴趣的人
我使用了一些PowerShell来实现脚本自动化。虽然环境似乎比Unix shell被考虑的要多得多，但实际上，使用对象而不是文本流更为繁琐，而且在过去30年中开发的许多Unix设施仍然缺失。
Cygwin仍然是我为Windows主机选择的脚本环境。在完成任务方面，它当然比其他选择要好。
- 我同意使用.NET对象而不是文本流。使用纯文本非常强大，而且命令链接也非常容易
- 使用对象是一种范式转换，需要一些习惯。但避免在涉及结构化数据的每个步骤(例如，无需确保字段被分隔)进行整体重新解析。
- @andy white@daishiman，我可以理解PowerShell的学习曲线，但是管道对象比管道文本更灵活。@理查德是对的。：)
- 但这不仅仅是学习曲线。很难与纯文本的力量争论。很难与30多年来处理文本的工具争论。
- 汽车制造商也很难与超过1000年的马匹争论。我不想轻率行事。仅仅指出过去的成功并不能消除创新的潜在好处。
- 我同意你关于创新的观点。我不同意管道对象比管道文本更强大的观点。如果您是管道对象，则所有命令行工具都必须了解对象。纯文本是所有语言都能理解的最小公分母。
- 对象可以更灵活，但这并不意味着解析它们是微不足道的。是的，对于文本，您有格式化问题，但是awk、sed和perl基本上解决了这个问题。当对象没有兼容的方法时会发生什么？翻译对象比翻译文本困难得多。
- 另一件事：对于MSH来说，没有什么是Perl或Python所不能做到的，而且两者都是成熟的语言，可以完成更多的工作，而且由于它们比bash更冗长，但是与MSH差不多(而且可读性更高)，所以我仍然看不到它的优势。
- @戴希曼-我完全同意你的观点。处理对象或专用配置机制(而不是纯文本)是Windows在命令行上难以处理的原因。
- @Daishiman——对象的好处是当你想要一个属性时，你需要它——你不需要解析、猜测和转换。我不理解你关于"当对象没有兼容的方法时会发生什么"的观点——你能用另一种方式说吗？或者举一个问题的例子？谢谢。
- 问题是，如果您处理的是一堆不同的对象，那么您需要反省以处理它们的不同方法和属性，这意味着唯一的共同点是文本，因此您可以回到正方体，而不用使用出色的Unix文本工具。
- @戴希曼-我明白。在实践中，人们发现这不是一个问题，而是一个巨大的优势。也就是说，我可以看到，如果您是一个专家级的文本解析器，那么这将是一种需要学习的新技能，一开始可能会感到不必要和尴尬。再说一遍-任何帮助都是正确的工具。
- 我试图在Windows上通过cygwin使用bash，但是路径的正斜线和反斜线杀死了它。整个命令行生态系统需要相同的工作方式，否则会令人沮丧并容易出错。
- 我认为程序员尤其会理解对强类型属性的需求，而不是随机的Perlthon文本解析，在这种情况下，任何事情都可能出错，而您甚至不知道它是否为时已晚？^ ^
- Unix工具非常棒和先进。但取决于文本输出有这么多的列，而这个特定的列并不是我想要的那么好。如果命令沿行更改了怎么办？你整洁的小剧本被打破了。这并不是说你不能用PowerShell进行类似的文本操作。但是你有处理完全逼真物体的优势。PowerShell可能永远不会像bash等那样强大，但它确实正确地实现了这一点。
这里有很多很好的答案，这是我的答案。PowerShell已就绪，如果您…实例：
grep="选择字符串-模式"
sort="排序对象"
uniq="独一无二"
file="获取项目"
cat="获取内容"
perl/awk/sed不是命令，但实用程序因此很难比较，但您几乎可以在PowerShell中执行所有操作。
- 你能相信我们祖先被迫使用的神秘的四字母命令吗？
- @evgenisegev默认情况下，上述所有选项分别为sls、sort、gu、gi、gc。标签完整的长可读名称和一个系统中的短可键入名称。这对你来说是用户友好的进步。
我最近才开始认真地涉足PowerShell。尽管在过去的七年里，我在一个几乎完全基于Windows的环境中工作，但我来自于一个Unix背景，我发现自己一直在努力"unix fy"我在Windows上的交互体验。说得最少一点让人沮丧。好的。
将PowerShell与bash、tcsh或zsh之类的工具进行比较是公平的，因为grep、sed、awk、find等工具严格来说不是shell的一部分；但是，它们始终是任何UNIX环境的一部分。也就是说，像select string这样的powershell命令具有与grep非常相似的功能，并且在powershell中捆绑为核心模块…所以线条可能有点模糊。好的。
我认为最关键的是文化，事实上，各自的工具集将体现各自的文化：好的。
- Unix是一种基于文件的(通常是非Unicode)基于文本的区域性。配置文件几乎都是纯文本文件。另一方面，Windows在配置格式方面的结构一直都要高得多——配置通常保存在专有数据库(例如，Windows注册表)中，这些数据库需要专门的工具来进行管理。
Unix管理(以及多年来的开发)界面传统上是命令行和虚拟终端。Windows从一个图形用户界面开始起步，而管理功能最近才开始从完全基于图形用户界面的转变。我们可以期望在命令行上的Unix体验更丰富、更成熟，因为它在PowerShell上具有重要的领先地位，而且我的经验与此相匹配。根据我的经验：好的。
Unix管理经验的目的是使操作简单，只需最少的按键；这可能是由于历史上必须通过9600波特的缓慢拨号连接来管理服务器造成的。现在，PowerShell确实有别名，这对绕过相当冗长的动词名词标准有很大帮助，但是了解这些别名有点痛苦(有人知道比：alias | where {$_.ResolvedCommandName -eq""}更好的东西吗？).好的。
历史可以被操纵的丰富方式的一个例子：好的。
iptables命令通常是长篇大论的，如果不是bash中内置的许多简洁的历史操作特性之一，那么以细微的差异重复这些命令将是一种痛苦，因此插入如下的iptables规则：好的。
iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT好的。
第二次使用另一台相机("camera-2)只是发行：好的。
!!:s/-1-/-2-/:s/50/51好的。
意思是"执行先前的命令，但用-2-代替-1-，用51代替50。好的。
Unix的体验是为触摸打字员而优化的；人们几乎可以在不离开"家"的情况下做任何事情。例如，在bash中，使用Emacs键绑定(是的，bash还支持vi绑定)，使用ctrl pakbd和ctrl nakbd完成历史循环，同时使用ctrl a和ctrl e分别完成行首和行尾的移动…但它肯定不会就此结束。即使在PowerShell控制台中尝试最简单的导航，但不要从起始位置移动，否则会遇到麻烦。好的。
- Unix上的通用分页(无LA)等简单功能在PowerShell中似乎没有现成的功能，这有点令人沮丧，而且丰富的编辑器经验也不存在。当然，人们可以随时下载第三方工具来填补这些空白，但是如果这些工具只是"存在"的话，就像它们在任何风格的Unix上一样，那就太好了。
至少在系统API方面，Windows文化主要由支持框架(即COM和.NET)驱动，这两个框架都是高度结构化和基于对象的。另一方面，对Unix API的访问传统上是通过文件接口(/dev和/proc或(非面向对象的)C样式库调用进行的。因此，脚本体验与它们各自的操作系统范例相匹配也就不足为奇了。PowerShell本质上是结构化的(所有内容都是一个对象)，它基于bash和friends文件。由PowerShell程序员使用的结构化API非常庞大(基本上与现有标准COM和.NET接口集的庞大程度相匹配)。好的。
简言之，尽管PowerShell的脚本功能比bash(尤其是考虑到.NET BCL的可用性)更强大，但交互体验却明显较弱，特别是从完全由键盘驱动、基于控制台的角度(就像许多Unix头一样)来看的话。好的。好啊。
- 您会问"任何人都知道比以下更好的东西：alias where$u.resolvedcommandname-eq""？"。.alias -Definition *property或其他模式如何？我认为您的答案的问题在于，您将shell和控制台混为一谈：请记住，您可以选择具有不同编辑选项的控制台。他们故意让DOS控制台编辑中断，以鼓励人们使用其他控制台，如ISE。
- 顺便说一句，您的!!示例可以在PowerShell中以(h -c 1) -replace '-1-','-2-' -replace '50','51' | iex的形式写入，但对于单个命令来说，向上箭头和编辑更容易。如果你想通过很多命令来实现这一点，我认为PowerShell会赢。重复10个以命令255结尾的命令和您的编辑：(h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iex也可以使用PowerShell的历史来做Linux shell中闻所未闻的事情；如果您回顾性地想知道一个命令运行需要多长时间：h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }。
- @关于你的评论，邓肯是关于shell和控制台的——我认为这只是bash和ps之间的一个根本区别；也就是说：bash希望提供某种交互体验，而ps将其"留给"其他东西。我对ISE控制台没有太多的经验，但从我的记忆中，它也没有丰富的交互经验。
- @邓肯，是的-这是一个很好的观点，关于PS在巧妙的历史技巧方面的能力。
- @邓肯…但是，尽管您断言在Linux shell中有些事情是闻所未闻的：fc -e"sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
- 我不是说那是不可能的。老实说，如果我想重复一些命令，我可能会写一个脚本。ISE很好，但是文档记录不好，需要不同的工作方式。我最近才找到shift+enter输入多行命令(或将多个命令作为单个历史项目)。它还具有代码片段、智能感知、颜色突出显示、调试器等。它没有搜索(除非我还没有找到)，但它允许您安装附加组件，所以可能有一个。
无论如何，我不是一个非常有经验的PowerShell用户，但是我接触到的那一点给我留下了深刻的印象。您可以将内置的Cmdlet链接在一起，以便在Unix提示下执行任何操作，而且还可以执行一些其他操作，例如导出到csv、html表，以及执行更深入的sys admin类型的作业。如果您真的需要类似于sed的东西，那么总是有unixutils或gnuwin32，您可以很容易地将其与PowerShell集成。
但是，作为一个长期使用Unix的用户，我很难适应命令命名方案，如果我了解更多的.NET，我肯定会从中受益更多。
所以从本质上说，如果它的窗口的唯一性不构成问题的话，我认为它是值得学习的。
- 有一个开源项目"pash"，允许您通过mono在其他平台上运行PowerShell。tinyurl.com/6dyoso
- 哇！谢谢你的小费，我迫不及待想试一试
最近的实验让我深入了解了PowerShell和.NET调用的深度，我必须说PowerShell可以取代Cygwin和UnixShell。
我不确定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来实现他们的目的。
如果你喜欢shell脚本，你会喜欢powershell的！
从微软命令shell(ars-technica)的指导教程开始。
- 我不确定你的结论-但这篇文章看起来很有用。谢谢。
- 我一点也不明白。我喜欢shell脚本，因为它是免费的，可以在我所有的计算机上运行。正如stroustrup所说，"要说服我，世界还需要另一种专有语言……特别是(一种)与特定的专有操作系统紧密集成。"
- 我喜欢shell脚本，并且我容忍PowerShell。它的命令和语法都很糟糕。非常长的命令和选项，没有任何有用的命令完成。如果有的话，我还没找到。太多的特性塞进了应该分开的单个命令中。奇怪的变量和转义语法只有DOS批处理程序员才能喜欢。
- @赞林克斯-你说的对，没有找到东西。所有命令都有别名，其中许多命令同时与DOS和UNIX命令(ps、dir、rm、ls、kill、history、man、cat、clear等)匹配。这些命令的名称很长，因此具有有意义的名称。非常适合脚本-当一个新用户需要使用和维护它时，它会有所帮助。有针对Cmdlet、函数、变量、路径、参数等的选项卡扩展。大部分语法来自Unix shell，您在讨论什么转义语法？``不用于转义，因为它是Windows中的路径分隔符。
- 写输出"这是一个"测试。真的，把角色加倍得到两个。但要在不解释变量的情况下输出字符串，可以使用反勾号。缺乏一致性？对。很难记住？对。有时您必须使用-literalPath参数。
- @Manojlds:看看这个：stackoverflow.com/questions/527772/&hellip；
- @赞林克斯-你的论点无效。要停止解释变量，请使用'(单引号)。对于双引号，同样使用write-output 'this is a"test"'。您所指的问题是对于regex，而对于regex的转义在任何地方都有效。PowerShell也有这里的字符串/逐字字符串。甚至Java也没有这些！尝试在Java中逃脱正则表达式。你有时也不使用文字路径。你需要的时候就用。LiteralPath逐字处理通配符，不展开它们。当你的文件有它的时候你就用它。它给你更多的选择。
- @Manojlds：与bash shell相比，PowerShell充满了毫无意义的不一致性，只是令人困惑。在bash中，在任何地方都使用相同的转义字符，并且文件路径像字符串一样转义。你不需要一个特殊的参数。如果展开一个变量，其中包含特殊字符，将其放在双引号中，并且内容是安全的，则无需调用函数来重新转义它。
- @赞林克斯-没有不一致之处。即使是write-output"this is a `"test`""也起作用。只需使用`而不是```。逃避是为了帮助你，这样你就不会错过逃避的东西。不需要使用它。你在想，其他帮助你和防止错误的选择是不一致的。
当您将PowerShell与cygwin/perl/shell组合进行比较时，请注意PowerShell仅代表该组合的"shell"部分。
但是，您可以从PowerShell调用任何命令，就像从cmd.exe或cygwin调用一样。它不会重新实现指定的函数，而且肯定无法与Perl进行比较。
它"只是"一个外壳，但它使编程更容易，为.NET世界提供了一个舒适的界面。
还要记住，PowerShell需要winxp、srv2003或更高版本，这可能会造成问题，具体取决于您的IT基础架构。
更新：
我不知道我的答案会引发什么样的哲学争论。
我在问题的上下文中发布了我的答案：将PowerShell与Cygwin、Perl和Bash进行比较。
PowerShell是一个shell，因为它在内置命令、commandlets、用户函数和外部命令(.exe，.bat，.cmd)之间没有语法差异。只有调用.NET方法不同于在调用中添加命名空间或对象。
它的可编程性源于.NET框架，而不是特定于PowerShell"语言"的任何内容。
我认为，只要Bugzilla或Mediawiki作为PowerShell脚本在Web服务器上运行，PowerShell就是一种"脚本语言"；)
在此之前，请欣赏这些比较。
- 是的，我想当我谈论Unix"shell"时，我还提到了Unix附带的所有常规实用程序，如grep、awk等。我只是想知道PowerShell是否提供了现成的类似实用程序。
- PowerShell不仅仅是一个外壳。它是一种脚本语言。我想知道它在什么方面无法与Perl相比？我承认这还不够成熟，但除此之外，我看不出差距。
- @Ebgreen，你的评论到底是什么意思？我同意任何shell或脚本语言在本质上都是相似的，但我更想知道PowerShell与bash/perl/其他unix shell/scripting语言的具体功能。
- PowerShell的功能范围非常广泛。它是一种交互式、可组合的shell——一种丰富的交互式脚本语言——一种编程语言，它还具有一套丰富的oo&tesxt实用程序功能(即相当于grep/awk/etc)。
- @安迪-我理解Devio的说法，PowerShell不如Perl强大。我不相信这是真的，我只是想知道为什么他认为是这样。
- 这是一个很好的观点。在PowerShell中，您可以找到很多关于如何通过HTTP解压或下载文件的文章。虽然你能做到，但那不是它的力量。你最好叫一个exe来完成这个任务。它是批量生产的，但是有很大的改进。
- 我倾向于同意PowerShell主要是shell的概念。我在PowerShell中完成了一些构建和部署脚本，我发现随着我的脚本变大，作为一种语言的PowerShell不能很好地处理增长。我的代码看起来相当笨拙，很难维护。也就是说，对于bash和任何其他sh衍生产品，这也可能是正确的。对于小脚本，PowerShell优于Cmd，但除了相对简单的内容之外，我更喜欢像python这样全面的内容。(我想我可能是"做错了"，但在我的书中，高学习曲线是一个打击。)
tl；dr——我不讨厌Windows或PowerShell，我只是不能在Windows或PowerShell上做任何事情。
我个人认为，PowerShell充其量也没什么吸引力。
- 目录路径的制表符完成不复合，要求用户在每次名称完成后输入路径分隔符。
- 我仍然觉得Windows甚至没有路径或路径的概念，没有可访问的用户主页指示器~/，缺少一些@environment://somejibberish/%user_home%。
NTFS仍然是一个烂摊子，而且似乎永远都是，祝你航行好运。
Cmd-esque接口，恐龙Cmd.exe在PowerShell中仍然可见，edit->mark仍然是复制信息的唯一方式，并且只能以矩形块的可见终端空间进行复制。而edit->paste仍然是将字符串粘贴到终端的唯一方法。
把它涂成蓝色不会使它更吸引人。不过，我不介意微软开发人员对颜色有兴趣。
窗口总是在屏幕的左上角打开，对于使用垂直任务栏的人来说，这非常烦人，特别是考虑到Windows任务栏将覆盖窗口的唯一一个允许访问复制/粘贴功能的角落。
我不能说太多，因为窗户里有工具。据我所知，有一整套开放源码、免费许可的cli工具和PowerShell附带，它们都不是一种彻底的失望。
- PowerShell wget对GNUwget采用了看似无法比拟的论据，这要感谢希望的微光，因为希望是可携式的无用的。
- PowerShell POSIX与bash不兼容，特别是不处理&&运算符，使得最简单的条件命令后面没有任何内容。
我不认识男人，我试过了，我真的试过了，我还是试着试着试一下，希望下次我打开它的时候，它就没什么用了。我不能在PowerShell中做任何事情，而且我几乎不能用真正的项目将GNU工具引入Windows。
mysygit给了我恐龙的cmd.exe提示和几个GNU工具，它仍然是非常令人失望的，但最后路径完成工作。git命令将在git bash中运行。
Mintty for MySysGit在MySysGit的环境中提供了Cygwin接口，使复制和粘贴成为一件事情(选择复制(鼠标)，shift+ins要粘贴，多么现代…)。然而，像git push这样的东西在Mintty中被破坏了。
我并不想咆哮，但我仍然看到Windows上的命令行可用性存在巨大的问题，即使给定了类似cygwin的工具。
附言：仅仅因为在PowerShell中可以做一些事情，就不能使它可用。可用性比能力更深刻，当我试图将产品作为消费者使用时，我倾向于关注它。
- 打开快速编辑模式？选择并按Enter键进行复制，按ctrl-v键进行粘贴，无需再进行编辑->标记或编辑->粘贴。在"首选项"中，设置窗口位置并取消选中"让系统位置窗口"。制表符完成不仅仅是完成文件系统路径，它还完成变量名、命令名、对象属性，您可能要键入.或[来访问属性或索引，因此它不能在末尾添加路径分隔符。确切地说，哪个PowerShell工作组？哪个PowerShell POSIX？它不想把GNU工具带到Windows中，也不想成为与bash兼容的btw。
- 是的，我知道这并不是在试着去狂欢。我没有在原来的帖子里这么说。我会说哪个w是二进制的，但是在power shell中没有"which"命令：(我不记得buy-i-readpowershell在哪里应该与posix兼容
- 回复："不，哪个"->(get-command wg*.exe).Path。回复：bash completion and readline->leeholmes.com/blog/2012/09/13/&hellip；通向github.com/lzybkr/psreadline
PowerShell中的Cmdlet非常好，工作可靠。他们的目标取向吸引了我很多，因为我是一个爪哇/ C开发者，但它根本不是一个完整的集合。因为它是面向对象的，所以它错过了POSIX工具集的大量文本流成熟度(比如awk和sed)。
对于热爱OO技术和热爱POSIX工具成熟度这两个难题，我发现最好的答案是同时使用这两种技术！PowerShell的一个重要方面是它可以很好地将对象通过管道传输到标准流。默认情况下，PowerShell使用对象管道来传输其对象。这些不是标准流(标准输出、标准错误和标准输入)。当PowerShell需要将输出传递到没有对象管道的标准进程时，它首先将对象转换为文本流。因为PowerShell做得很好，所以它是一个非常好的地方来承载POSIX工具！
最好的posix工具集是gnuwin32。安装确实需要5秒钟以上，但值得一提，据我所知，它不会修改您的系统(注册表、c:\windows\*文件夹等)，除非将文件复制到您指定的目录中。这非常好，因为如果将工具放在共享目录中，许多人可以同时访问它们。
GNUWIN32安装说明
下载并执行exe(它来自sourceforge站点)，将其指向合适的目录(我将使用C:\bin)。它将创建一个GetGnuWin32目录，在该目录中运行download.bat，然后运行install.bat(不带参数)，在该目录之后，将有一个C:\bin\GetGnuWin32\gnuwin32\bin目录，它是Windows计算机上最有用的文件夹。将该目录添加到您的路径中，您就可以开始了。
为什么不两者都用呢？在cygwin中调用PowerShell脚本，就像其他解释脚本(如perl等)一样。
我做的足够多，以至于我写了https://bitback.org/jbianchi/powershell，让bash包装器在cygwin中调用powershell.exe。它可以用作powershell.exe.ps1脚本的第一行shebang(因为powershell也使用""作为注释)。示例请参见https://bitback.org/jbianchi/powershell/wiki/home
我还没有看到PowerShell真正开始运行，至少还没有。因此，除非团队中的其他人已经知道，否则学习它可能不值得。
对于您的困境，您最好使用其他人可能会落后的脚本语言、您提到的Perl或Ruby或Python等其他语言。
我认为很大程度上取决于你需要做什么。就我个人而言，我一直在使用Python编写自己的个人脚本，但我知道当我开始写一些我永远无法传递的东西时——所以我尽量不要做任何太革命性的事情。
在几行中，cygwin和powershell是不同的工具，但是如果安装了cygwin，则可以在powershell会话中运行cygwin可执行文件。我已经习惯了PowerShell，现在我不再使用grep、sort、awk等。PowerShell中有很多内置的备选方案，如果没有，您可以在那里找到一个Cmdlet。
我发现自己使用的主要工具是ssh.exe，但在PowerShell会话中。
它很好用。
PowerShell的功能非常强大，比Unix shell的标准内置程序更强大(但这仅仅是因为它包含了许多通常被解压到子程序中的功能)。另外，考虑您可以用任何.NET语言编写小程序，包括Ironpython、IronRuby、Perlnet等。或者，您可以从PowerShell中简单地调用cygwin命令，忽略所有额外的功能，它将类似于bash、korn或其他任何功能…
- 我认为您可能错过了Unix shell的设计目标。不敲PowerShell(希望自己了解更多)，但您需要了解Unix工具才能做出这样的声明。
- @Xepoch-不，我认为你错过了PowerShell的设计目标。PowerShell可以以与Unix shell相同的方式执行所有操作。然而，当您使用ps的对象管道系统而不仅仅是解析文本输出时，真正的力量就来了。所以，PowerShell可以做bash或korn可以做的，但不能做PowerShell可以做的。
- 我只是不太了解PowerShell，不足以对其提出批评，但正如您清楚地知道的那样，Unix shell的目标不一定是完全全面地替换外部工具，而应该是它周围的控制结构。同样，我现在不能比较也不能对比，而是提升PowerShell，因为它有更多的内置组件，这不一定是Unix shell的优点。
- @Xepoch-关键是，你可以选择你想用哪种方式来做。您可以使用内置shell的所有优点，或者您可以忽略并像Unix那样执行它。这是你的选择。选择是好的，对吗？
您也可以尝试使用bashwin在Windows上运行bash脚本https://github.com/skanga/bashwin.
我发现PowerShell编程不值得这么做。
我在Unix下有几年的shell脚本编写经验，但我发现使用PowerShell做任何事情都非常困难。
许多函数似乎都要求您询问Windows管理界面并发出类似SQL的命令以获取所需的信息。
例如，我想编写一个脚本，从目录树中删除具有特定后缀的所有文件。在Unix下，这将是一个简单的…
1
| find . -name \*.xyz -exec rm {} \; |
在与Scripting.FileSystemObject和WScript.Shell进行了几个小时的讨论，并发出了"从win32 shortcutfile(其中drive='&drive&；drive&；and path='&searchfolder&；searchfolder&；"')中选择*"后，我最终放弃了Windows资源管理器的搜索命令，只需手动执行即可。也许有办法做我想做的事情，但我没有看到任何明显的东西，而且在msdn网站上的所有例子都是如此的微不足道以至于毫无价值。
编辑heh，当然，当我写这篇文章的时候，我又翻了一番，发现我遗漏了什么：删除项目命令的-recurse选项是错误的(如果使用get-help remove-item -detailed)。
我一直在尝试"删除项目-过滤器"*.xyz'-重复使用"，但它不起作用，所以我放弃了它。
原来你需要使用get-childitem -filter '*.xyz' -recurse | remove-item。
- 我认为您将Windows脚本主机(WSH)与PowerShell混淆了。他们完全不同。
- 例如，如果要删除以.tmn结尾的所有文件，可以发出以下命令：get childitem c:-include*.tmn-recurse foreach($remove item$u.fullname_
- @我试过了，但好像不管用。经过一些争论之后，似乎你需要的是*.tmn(而不是.tmn)。
- 我再也不能恭敬地不同意了，我决不是一个靠窗的人。我发现编写ps比bash容易得多。PS更一致。对于bash，您调用的任何控制台实用程序都有其自己的语法和独特的行为，bash语法本身相当神秘。PS的语言特性(如匿名函数(脚本块)、参数验证、高级函数等)以及模块的可移植性概念和许多其他特性更加强大。主要是，最大的原因是你总是听到关于ps，对象胜过文本。不过，bash还是更快。