Windows从来没有像样的外壳的原因是什么？[关闭]

我正在阅读有关SO的主题：为什么脚本语言（例如...）不适合作为Shell语言？。特别是，我喜欢JörgW Mittag的回答，从中我学到了一些有趣的东西Windows PowerShell。因此，经过20多年的努力，Windows终于有了一个经过精心设计的外壳程序（Windows 1.0-1985，PowerShell稳定版-2009）。另一方面，自1978年以来，Unix系统就拥有大量的外壳。我读过一些有关MS求职面试的文章，给我留下了非常“怪异”的印象。我想知道为什么与使用这些工具进行所有工作的Unix人员相比，他们不需要命令行工具。

iPod，iPhone（与此有关的任何手机）和iPad拒绝的原因相同：命令行不是Windows中用户与计算机进行交互的主要渠道。它在UNIX或GNU / Linux中-这就是为什么它们更成熟的原因。与Windows相比，为什么Linux GUI桌面这么长时间是垃圾（Mac OS有点作弊，因为它们免费获得了unix命令行），这是同样的论点。

也许我过于简化了，但我认为这是一种文化上的事情：

1. 在Microsoft文化中，开发人员专注于为用户编写程序。这些程序都是基于GUI的。
2. 在Unix文化中，开发人员专注于为其他开发人员编写程序。这些程序很小，专注于做好特定的事情。

请注意，没有理由使Microsoft成为唯一为Windows编写Shell的人。写bash的人不同于写* nix内核的人。您甚至不需要root特权。当我不喜欢sysadmin安装的外壳程序时，我已经编译了自己的外壳程序以供使用。如果确实有一个更好的Windows shell需求，那么有人会写一个。

我想，因为从来没有足够的电话征求意见。

从Windows 98开始，Windows Scripting Host就已作为标准安装（我猜它早于此）。VBScript非常强大。或者您可以轻松编写一个可以访问整个Windows API的命令行工具。

简而言之，Powershell只是朝着同一方向迈出的又一步。COM不再流行，因此WSH已经成为一个学习过程。但是.NET是Windows世界中的当下大事，从.NET背景学习Powershell相对容易。

我认为Powershell出了问题的地方之一就是也试图吸引* nix人群，它的所有别名使它在显然不是Bash时看起来像Bash。

除了命令行开关以外，Powershell中的管道连接也有很大不同，这确实是您拿起它时应该学习的第一件事。

老实说，它更像是一种脚本语言，一种La Perl，而不是一种外壳，一种La Bash。如果尝试将其用作主外壳，则会遇到一些严重的陷阱。

例如，尝试从Powershell执行简单的SVN转储。它不能很好地处理stdout中的二进制数据。另一方面，由于其内置的xml类型，因此操作SVN日志绝对是梦想。

因为开发第二个并行Windows工具集几乎不需要，也很痛苦。

通过GNU系统上的辅助程序（如sed，find，xargs等）的数量和功能，shell变得强大起来。重新实现这些工具需要进行大量工作，事实证明，仅在Windows之上构建POSIX合规性层就容易得多。Cygwin就是这样的POSIX合规性层，它满足了外壳用户在被迫使用Windows时所具有的大多数需求。

我个人可能会认为，既不愿意跳过POSIX和Linux潮流又仍然充分致力于shell编程的开发人员社区是如此之小，以至于花了20年的时间才开发出稳定的shell。

这是一个忽略阴谋理论的问题之一，可能没有一个单一的答案，这是历史学家可以在没有找到确切答案的情况下永远争论不休的问题。

我的印象是，外壳的功能不是立即显而易见的。我开始在Windows 3.1中进行编程，几乎没有使用Shell。一切都是通过Visual C ++ IDE完成的，我从没看过makefile和DOS批处理文件如此有限，以至于我很少尝试使用批处理文件来自动化比基本备份更复杂的事情。当时我所读的Windows编程书籍（我对Petzold都有美好的回忆）都没有讨论过使用Windows Shell进行任何事情。直到我开始使用Linux并对Linux进行编程之后，我才知道强大的Shell可能有用。我记得当Windows出现时，它是如此令人兴奋，因为您不必使用旧的command.com不再。我们终于有了一个漂亮的界面，可以使用多个字体同时运行多个程序，而无需TSR ...

我认为大多数从Windows开始的程序员都没有使用强大的Shell的经验，因此，不必感到迫切需要为Windows实现一个。在Linux上工作并喜欢Shell的程序员更喜欢在Linux上工作，因此不愿意花时间在他们不太愿意为Windows实施的环境中工作，特别是考虑到（如上所述）另一个问题）是否还需要实现所需的所有CLI工具以及外壳本身。

Linux越来越受欢迎，这可能是Microsoft最终安装合适的shell的主要原因。随着越来越多的人意识到shell对它有用的知识，越来越清楚地表明Windows缺少重要的工具。

如果您认为Unix外壳“不错”，那么至少有几十个Windows外壳已经“不错”了。在汉密尔顿的C shell是相当接近从UNIX C shell（但要注意的是，C shell中从未有过特别巨大的市场渗透率在Unix）。相当多的人还使用了JPSoft的各种外壳（4DOS，4NT，现在称为Take Command）已有相当长的时间了-您可以从名称中猜测到4DOS可以追溯到MS-DOS时代。

如果您坚持使用Microsoft发行的shell，大约在15年前，则该Windows NT Resource kit曾经包括PD Korn shell ¹的NT端口，以及相当数量的Unix-ish实用程序。它可能没有足够的能力来运行许多没有修改的shell脚本，但是足以处理大量的使用，尤其是大量的交互工作。

¹老实说，我不知道它是那个完全相同的shell的端口，或者只是一个非常相似的东西-我用它来验证它是否像我记得Unix shell一样令人讨厌，并留给了它。

Windows具有不适合脚本编写的设计功能。这是使图形界面成为主要操作模式的结果。许多工具没有功能性的命令行界面。没有合适的命令行界面，很难生成一个好的shell。

通常，在Windows中需要编写脚本的内容需要在应用程序窗口的各个位置模拟鼠标单击和击键。生成的脚本可能非常脆弱。描述命令语言的位置并不是一件容易的事，因为相关的几何图形并不容易获得。

Windows在早期版本中也没有功能性的管道机制。正如描述的那样，第一个进程将运行，其输出将保存到一个临时文件中。该文件将用作下一个命令的输入。这可能会占用大量磁盘，并且如果没有足够的临时空间将失败。Unix管道以最小化延迟的方式传递内存中的数据并调度进程。

当Windows NT在1993年发布时，MS便将其转移到了以前由Unix服务器占据的领域，当时，人们对POSIX的兼容性和可移植性有了很大的关注。但是它并没有完全做好这项工作-相反，它的用户更多是使用更好的硬件的台式机人群（这些日子是486dx 50MHz和32MB RAM接近高端的日子），并且希望有更好的OS。但是他们对壳不感兴趣，所以一切都消失了。到Windows Server 2000时代，这是第二次尝试打入这个市场的尝试，我认为MS已经意识到它们在shell方面很弱-因为管理员喜欢shell脚本-但即便如此，他们还是花了一些时间来解决这个问题。