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

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

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

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

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

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

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

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

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

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

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

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

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