Linux命令行厉害，其实Windows的也很强

像Cygwin这样的第三方工具可以很好地将许多核心GNU工具和兼容性库移植到Windows，但是它们无法运行未移植的，未经修改的Linux二进制文件。这非常重要，因为许多Ruby，Python，Node包和模块依赖于或包装Linux二进制文件，或者依赖于* NIX运转状态。

这些原因促使微软通过在 Windows的子系统Linux（WSL)上本地运行真正的，未经修改的Linux二进制文件和工具来扩展Windows的兼容性。使用WSL的用户现在可以在同一台机器上并行下载和安装一个或多个Linux发行版，并使用apt / zypper / npm / gem / etc.安装和运行绝大多数Linux命令行工具以及他们喜欢的Windows应用程序和工具。

但是，还有一些控制台提供的东西尚未被非Microsoft终端采用：具体来说，Windows控制台提供命令历史记录和命令别名服务，从而无需每个命令行shell（特别是）重新实现相同的功能。

把 Windows 命令行远程化是困难的

正如我们在 Command-Line Backgrounder 一文中所讨论的那样，终端最初与它们所连接的计算机是分开的。快进到今天，这种设计仍然存在：大多数现代终端和命令行应用程序/shell 等等是由进程或机器边界分隔的。

在基于 *NIX 的平台上，终端和命令行应用程序的分离并通过简单的字符进行通信的概念导致 *NIX 命令行易于从远程计算机/设备访问和操作：只要终端和命令行应用程序可以通过某种类型的有序串行通信基础架构（TTY/PTY 等）传输字符流，远程操作 *NIX 机器的命令行是非常简单的。

但是在 Windows 上，许多命令行应用程序依赖于调用 Console API，并假设它们与控制台本身在同一台机器上运行。这使得远程操作 Windows 命令行 shell/工具等变得很困难：在远程计算机上运行的命令行应用程序如何调用在用户本地计算机的控制台上的 API 呢？更糟糕的是，如果远程命令行应用程序通过 Mac 或 Linux 机器上的终端访问，它如何调用 Console API 呢？！

很抱歉开个玩笑，但我们将在以后的文章中更详细地阐释这个主题！

启动控制台或者不！

通常，在基于 *NIX 的系统上，当用户想要启动一个命令行工具时，他们首先会启动一个终端。然后终端启动一个默认的 shell ，或者可以配置为启动一个特定的应用程序/工具。终端和命令行应用程序通过伪终端(PTY)交换字符流进行通信，直到一个或两个字符终止。

然而，在 Windows 系统上，事情就不一样了:Windows 用户永远不会启动控制台(conhost.exe)——然而他们会启动像是 Cmd.exe，PowerShell.exe，wsl.exe 等等这样的命令行 shell 和应用程序。Windows 系统将新启动的应用程序连接到当前控制台(如果是从命令行启动的话)，或者连接到新创建的控制台实例。

现在要说的?

是的，在 Windows 系统中，用户启动命令行应用程序，而不是控制台本身。

如果用户从现有的命令行 shell 启动命令行应用程序，Windows 通常会将新启动的 .exe（可执行文件） 附加到当前控制台。否则，Windows 会将一个新的控制台实例与新推出的应用程序绑定在一起。

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!