Shell scripting, with Steve Lee (Microsoft) - S04E04
32:14 Share

欢迎收听 Console DevTools 播客的另一期节目。我是 David Mitten，Console.dev 的首席执行官，Console.dev 是一份免费的每周电子邮件简报，内容是面向经验丰富的开发人员的最佳工具和测试版发布。我是 Jean Yang，Akita Software 的首席执行官，Akita Software 是理解您的 API 的最快捷简便的方法。

在本期节目中，我和 Jean 与 Steve Lee 进行了交谈，他是微软 PowerShell 团队的首席软件工程师经理。我们首先介绍了 PowerShell 是什么以及其基于对象的方法为何引人注目，然后探讨了 2016 年在微软开源项目的情况。我们讨论了转向使用 GitHub 的过程以及大规模管理开源项目的情况，如何在微软的目标以及社区的功能、错误和用户请求之间取得平衡。

我们将把时间控制在 30 分钟内，所以让我们开始吧。我们现在与 Steve Lee 交流。Steve，感谢你加入 Console 播客。当然，我很兴奋。让我们从简短的背景介绍开始。请告诉我们你目前在做什么以及你如何走到今天这一步。当然可以。目前，我是 PowerShell 的软件工程经理，也是 Windows 的 OpenSSH 端口的负责人。我在微软工作了 20 多年。我实际上是在 2000 年 1 月加入的。

我当时不是刚毕业就加入的。我实际上在波音公司做了一年的 Unix 支持工作。这实际上并不是一个非常有趣的故事。能够加入微软纯属偶然和运气。基本上，波音公司有裁员的历史，他们发了一封电子邮件说即将裁员。所以我不想继续待在那里。我在微软有一些做 Unix 版 Internet Explorer 项目的联系人，很多人可能不知道这个项目的存在。

但在那时，Internet Explorer 是主要的浏览器，人们仍然想在……当我提到 Unix 时，我指的不是 Linux。我指的是 AIX、Solaris、HPUX 等所有经典的东西。哇。所以我转到了那个团队。但我不知道的是，这是一个非常短命的项目。所以大概一年后，它就……

基本上完成了。所以我不得不寻找另一个团队加入。我最终加入了 WMI 团队。任何熟悉 Windows 的人都可能知道 WMI 是什么。如果你不知道，你可能不知道它是什么。但基本上，它是一个抽象层。因此，您可以使用基于 SIEM 的对象模型对 Windows 的各种内容（如存储、网络计算）进行各种管理。

这来自 DMTF（桌面管理任务组）。很长一段时间里，我实际上也是其中一员。我的唯一正式出版物实际上是关于这个名为“物理计算机系统视图”的 DMTF 规范。

如果你对此感兴趣，我们可以讨论一下。但这都是历史了，因为 Sim 没有像微软预期的那样大规模发展。WSMAN（一种远程处理协议）和 WinRM（WSMAN 的 Windows 实现），我在这些协议被构思时就在这些团队中。那已经是很久以前的事了。然后随着时间的推移，微软内部、Windows 内部进行了一些重组，PowerShell 团队、WMI 团队和 WinRM 团队都合并了，因为它们都是管理平台的组成部分。

这可能是在……我想说是 2016 年左右。我必须查看我的历史记录才能确定年份，但是，是的，

所以我在思考我的下一步是什么，因为我当时在 WMI Winter 等团队工作了一段时间。所以有一些讨论，比如，“PowerShell 的下一步是什么？”因为我当时并没有正式加入 PowerShell 团队。所以讨论的重点是，好吧，如果我们真的希望 PowerShell 变得更重要，我们就真的需要以 Linux 为目标。在那时，Azure 也试图更多地以 Linux 为目标。我想我们一定已经有了，或者正在经历首席执行官的变动，对吧？这将是从鲍尔默到萨蒂亚·纳德拉。

所以为了以 Linux 为目标，你必须是开源的，对吧？所以这是一个重要的讨论。好吧，这是一项 Windows 专有技术。我们如何将其开源？我们如何现在支持跨平台？对我来说，这似乎非常有趣，因为在此之前，我一直在做完全是 Windows 专有技术的工作，对吧？

大部分情况下都是如此。所以我说道，好吧，这对我来说似乎是一个好机会。然后我成为了那个团队的工程师经理。在那时，我已经是一名经理了。但对我来说，这是一个新的东西，令人兴奋。我们将弄清楚如何做到这一点

在鲍尔默领导下的微软，开源并不是你经常谈论的事情，对吧？所以这是一个很大的挑战。我认为我所知道的在那个时候真正采用开源路线的另一个团队是 .NET 本身。当然，PowerShell 是基于 .NET 的。所以如果他们没有开源，我们就无法做到这一点。所以我们是在开辟新的天地。现在，很显然，在萨蒂亚领导下的微软今天对开源更加开放。有更多的贡献。它被更多地使用了。所以情况发生了很大的变化。但在那些日子里……

有很多与律师的讨论。对我们的代码库进行了大量的代码审查，以确保我们发布的内容不会打开专利等等。这是一个非常漫长的过程。无论如何，为了简短起见，这是一个非常激动人心的时刻，因为我们正在为我和我的团队做一些全新的事情。

你知道，对于 Windows，如果你想进行新的开发，你不会公开它。你不会在它真正公开之前谈论它。而在开源中，我们甚至在开始之前就讨论了未来的计划，因为我们希望尽早获得反馈，并说，“嘿，你同意吗？你不同意吗？”很多时候人们不同意，但希望我们仍然做出了正确的决定。无论如何，这就是我今天所处的位置，就像做开源一样。当然，随着时间的推移，我做的不仅仅是 PowerShell。PowerShell 库也加入了我的团队。

还有 OpenSSH 项目。所以今天我的投资组合比仅仅是 PowerShell 大得多。

酷。是的，感谢你的介绍，Steve。我很想为我们的听众稍微放大一点，让你谈谈什么是 PowerShell？它是如何产生的？它与 Windows 命令提示符有何不同？顺便说一句，我在微软实习期间实际上使用过 PowerShell。我想，这太酷了。我很想了解更多关于它的信息。当然。我想澄清一下，PowerShell 最初被构思时，我并不在 PowerShell 团队，对吧？所以

PowerShell 经历了多个版本。老实说，我不知道它的全部历史。尽管 PowerShell 最初被构思时的原始 PM（项目经理）今天仍在我的团队中。他现在是一名软件工程师。

所以他们真正想要解决的一个重大挑战是，你知道，Windows 中的 CMD 实际上来自旧的 DOS 时代。它非常像在那里做最基本的事情。而 Windows，顾名思义，非常关注 GUI。所以 Windows 成功的一个很大程度上完全基于 GUI，图形界面，

随着时间的推移，人们喜欢它。但是，如果你需要向多个服务器扩展很多内容，那么 GUI 只能做这么多。GUI 不一定适合这种情况。但对于开发人员来说，使用 Visual Studio 很好。但有时你可以在控制台中提高效率，因为你可以直接做你需要做的事情。所以他们需要重新思考 Windows 的 shell 应该是什么样子。如果你看看像 Bash 和 ZShell 这样的经典 shell，

管道主要由将文本或二进制内容从一个命令传递到下一个命令组成。如果是文本，那么你必须使用像 grep 和其他东西这样的正则表达式来处理这些东西。他们将把这些东西拼凑起来。你希望工具不会更改文本的格式，因为现在它可能会破坏你的正则表达式，对吧？所以 PowerShell 的一个根本区别在于这个对象管道，你运行 PowerShell 术语中所谓的 cmdlet，它是一个改进的。

命令，它将输出一些结构化数据，通常像一个 .NET 对象。你可以检查它。你可以使用点表示法。所以对于任何从事编程的人来说，这都应该非常熟悉，这也意味着对于非开发人员来说，学习曲线会更高一些。但其理念是，你知道，你会调用像 get service 这样的东西，而 service 返回的不仅仅是文本。我的意思是，在控制台中，它被格式化为文本。

但它实际上是一个输出的对象，你可以检查它。你可以将其通过管道传递到另一个命令。你可以查询它。你可以将这些对象直接通过管道传递到另一个命令，例如执行操作，例如停止服务等等。所以这使得它非常强大，但它确实增加了一定程度的复杂性，因为你现在正在处理对象而不是纯文本。所以这基本上是 PowerShell 的价值主张。现在，还有其他方面。PowerShell 建立在 .NET 之上，这意味着你可以调用

基本上任何 .NET API，对吧？所以在一个普通的，例如，为了挑剔 CMD，你受到可用可执行文件的限制，以做你需要做的任何事情。而在 PowerShell 中，从某种意义上说，就像 VBScript，或者像 Python 之类的东西，你可以调用 API。因为它在 .NET 上，你可以调用本机 API。例如，你可以调用导出的 C 函数来获取你需要的任何东西。所以如果有人没有为你创建一个命令，但你知道有一个 API 可用，你可以在你的 PowerShell 脚本中调用它。这说得通。在什么时间点……

你建议人们转向，并非贬低的意思，真正的编程语言？界限在哪里？如果你拥有几乎与编程语言相同的函数，那么界限在哪里？你应该在什么情况下使用脚本，什么情况下使用编程？所以要明确的是，PowerShell 本身是建立在你所说的真正的编程语言之上的。它主要用 C# 编写，但它也有一些 C 部分，我们需要从中抽象出操作系统。所以我认为我们定位 PowerShell 的方式是，它实际上是一种粘合语言

而不是用于开发完整的应用程序。现在，我知道社区中有一些人使用 PowerShell 脚本构建了非常复杂的系统，我们将尽一切办法支持他们，对吧？但它并非为此目的而设计的。它实际上是用于……我们在团队中使用它的方式实际上是这样的，你知道，你正在尝试测试一些新的 .NET API。用几行 PowerShell 脚本编写它实际上比编写必须编译并完成工作的 C# .NET 代码要快得多。对。所以它使测试新事物变得非常容易，在承诺编写关键的正式开发代码之前进行原型设计。对。还有其他类似的优点，例如，你知道，脚本。我认为很多，我不认为它一定是，你知道，非黑即白。你应该使用脚本还是，你知道，编译语言，在不同的情况下，它是有意义的。对于很多 IT 专业人员来说，像

他们不想使用编译器，因为，你知道，使用 PowerShell 脚本，你不必担心针对不同的架构、不同的操作系统，因为我们支持 Mac、Linux 和 Windows 以及不同版本的 Linux。我们支持，你知道，X86、X64、ARM64。你只需编写一次脚本，它就像 Java 的“编写一次，随处运行”的承诺一样，对吧？存在一些限制，因为某些东西在不同的系统上是无法移除的，但是

所以它实际上是对你想要完成什么以及代码有多复杂的一种权衡。你当然可以在 PowerShell 中编写复杂的代码，但对于我们团队自己的需求，我们确实编写了一些 PowerShell 模块，它就像一系列 cmdlet。其中一些是用 PowerShell 脚本编写的，因为这样做更快。在其他情况下，我们会说，“嘿，我们真的需要用 C# 来编写这个，也许是因为性能方面的考虑，或者也许是因为维护方面的考虑，因为底层 API 用 C# 来做更简单。”所以……

很好。所以 Steve，我想回到你谈到 PowerShell 开源的那部分对话，并深入探讨一下。这个决定中涉及到什么？因为正如你提到的，这在当时对于微软的产品来说并不是一个典型的决定。这个过程是怎样的？这实际上花了一段时间。我不记得完整的的时间线。我想说我们可能花了大约一年的实际工作时间

来准备开源，然后我们才宣布它。当我们宣布它时，它无论如何也不是完全准备好了。所以有几件事。Windows 在那时，微软没有使用 Git。

对。他们使用的是专有的源代码控制系统。所以其中一部分实际上是将所有内容移动到 Git 仓库中，因为我们知道我们将把它放在 GitHub 上。而且，我们需要教育我们所有的工程师如何正确使用 Git，因为 Git 的工作方式与我们当时微软内部使用的专有系统非常不同。对。所以这是如何正确地做这件事的心理方面，而不是仅仅试图

你知道，把方形木桩塞进圆孔的情况。所以需要一些时间来真正理解正确的分支等等，因为，同样，Windows 的做法非常不同，因为 Windows 是一个大型项目。所以这是一个方面，就是学习新的工具，你知道，从专有软件转向开源公共软件，以便社区贡献者能够真正做出贡献。对。所以如果我们停留在专有软件上，他们就无法使用它。

所以这是一个方面。另一个重要方面是测试。在 Windows 专有代码库中，我们也有专有的测试框架。出于几个原因，我们无意开源这些东西。一个原因是我们不想支持它。二是随着时间的推移，因为 PowerShell 是一个多年的项目，不同的人开发了不同的框架，不同的测试。

所以这在当时是一个艰难的决定，但我认为这是一个正确的决定。我们实际上将使用一个名为 Pester 的开源框架编写所有新的测试。这花了很多时间。我们确实利用了一些现有的测试知识和测试数据。但本质上，我们只是编写了所有新的测试。我认为我们因此而变得更好，因为现在很多编写测试的人比他们第一次编写测试时更擅长编写测试，对吧？就像我们进行了一些分析一样，这并不是我们随意做出的决定。我们进行了大量的代码覆盖率分析，并说，“好吧，

我们在 Windows 专有系统中拥有数万甚至数十万个测试用例。我们想看看有多少实际上是重复的，重叠的相同的代码路径。结果发现有很多，对吧？所以即使我们移植了它，我们也不会获得很多价值，因为现在我们运行的测试要多得多，它们只是覆盖了相同的区域，对吧？所以它将花费更多的 CPU 和时间等等。

所以这最终是一个值得的决定，但这当然是一个让管理层犹豫的决定，对吧？就像这是一项巨大的努力。当然，作为专有代码，我们必须经过广泛的审查，不仅是法律方面的审查，还有团队内部的审查，例如，

可能有一些开发人员添加的注释并不，你知道，需要进行清理，让我们这么说，好吗？因为他们不希望任何人看到它在微软之外，对吧？就像，没有什么，像，非常糟糕的，但是，你知道，微软希望非常合规。当我们开源它时，有些事情我们不应该说。所以我会举一个简单的例子，

像 master 和 slave 这样的东西是非常经典的计算术语。如果你曾经在过去做过硬盘，你必须将一个驱动器设置为主驱动器，另一个驱动器设置为从驱动器。事情就是这样发生的。在现代，谁能想到这是一个好词？我们现在必须重新考虑这些事情。Partial Project 目前仍在 master 分支上，因为将其更改为主分支非常困难。这些是我们必须考虑并花费大量时间清理代码库的事情。

准备好了。所以这是一个很大的努力。然后另一个很大的努力是，当人们为 Windows 开发时，他们只认为这只会运行在 Windows 上。所以当我们真正地让它在 Linux 和 Mac OS 上运行时，

有很多决定是合理的。现在我们必须考虑，我们如何让它在 Windows 上运行？例如，斜杠就是一个明显的例子，对吧？例如，在 Windows 上，反斜杠是分隔路径的方式。而反斜杠实际上是非 Windows 系统上的转义符，对吧？所以我们如何让它工作？或者在 Windows 上，你总是有一个驱动器号，对吧？ABCD，无论是什么情况，在 Linux 或任何 Unix 系统上都不存在，对吧？所以我们如何解决这个问题？所以有很多变化是

在代码中进行调整。其中一些实际上非常复杂，因为许多基本决定都是基于 Windows 特性做出的，这些特性永远不会起作用，对吧？所以花费了很多时间来做这件事，以使其跨平台工作。

你是怎么做到的？你是否有像用于检测操作系统的 if-then 分支，或者是否有像翻译层这样的东西？PowerShell 中是如何实现的？这是一个好问题。所以我们实际上有，我想你可以说我们使用了三种不同的方法。一种是 Windows 中存在某些 API。所以我们确实有一些 PMVokes，这在 .NET 术语中是平台调用。

因为 API 不存在于 C# 中。我们必须调用一些底层的本机 API。在这些情况下，我们实际上有，有一个单独的 partial-native repo 项目为这些 API 提供抽象，对吧？所以有一个限制，而不是我们仍然使用的本机代码

但我们并没有增加它。我们只是保留它，因为它需要。所以这是一个方面，即拥有该抽象层。我们确实有很多 if-defs，因为没有理由编译一堆永远不会在 Linux 上运行的代码，例如，因为它特定于 Windows，对吧？我们也为 Linux 做了同样的事情。

但有些情况下，我们实际上有运行时决策，因为没有理由将其定义出来。所以它就像，“嘿，如果我在 Linux 上运行，或者如果我在 macOS 上运行，我将走另一条路。”所以这段代码可能存在于 Windows、Linux 和 macOS 上，但它只在特定系统上运行。我认为这些是最小限度地保留运行时内容的方法。大多数情况下，我们确实有大型 FDEF，因为如果代码永远不会在不同的操作系统上使用，就没有理由编译它。是的，这说得通。

Steve，你能谈谈房间里的谈话是什么样的，来说服人们让你在微软开源 PowerShell 吗？例如，你提出了哪些优点？他们提出了哪些反对意见？是的，我认为问题实际上是，你知道，如果你开源 PowerShell，这是否会让微软处于竞争劣势？对。在那时，我的意思是，PowerShell

被微软和微软的客户几乎所有人使用，对吧？因为如果你在做办公室工作，你会使用 PowerShell 来管理 Exchange 等等。如果你使用 Windows，你就会使用 PowerShell，无论你是否知道，对吧？尽管 CMD 仍然可用。所以我认为从业务角度来看，第一个决策点是，通过使其更广泛地可用，我们是否会失去任何东西？答案似乎是否定的，对吧？

然后问题是，对于 Azure 来说，对于 Azure 作为云服务的增长，你知道，我认为每个人都认识到，“嘿，我们必须以 Linux 用户为目标。”我不知道是否有人知道，但在某个时候，它被称为 Windows Azure，他们去掉了 Windows，因为他们想创造一种你只做 Windows 的印象。就像底层平台至少在那时运行的是 Windows，对吧？所以如果你有一个 Linux 虚拟机，它仍然运行在 Windows Hyper-V 上运行的 Linux 上。所以这是另一个决定。好吧，如果我们真的想帮助 Azure 使用率的增长，

PowerShell 是否有帮助？如果是这样，那么我们如何让 Linux 用户甚至关注 PowerShell 呢？所以我认为早期的策略并不是说，

因为我认为我来自 Unix 背景，你知道，如果你还记得我从波音公司得到的东西等等，你知道，很多人在 Unix 领域有这些经典的宗教战争，对吧？就像 KDE 与 GNOME 之间的战争等等。这些很有趣，但它们也不太有效率。我从中学到的教训是，人们坚持某些东西，因为他们知道它，他们并不一定想尝试新的东西。如果它更好，那就很好。但它必须比他们真正考虑转换要好得多，对吧？所以价值主张，我们最初的目标是人们

我们知道一些 Windows 企业开始关注 Linux。对于某些工作负载来说，这是有意义的。那么我们如何帮助 Windows 客户使用他们已经知道的技术（即 PowerShell）来管理 Linux，以及我们如何让他们在 Azure 中做到这一点呢？所以这就是商业主张。它就像，“好吧，如果我们在这里能够成功，我们可能会带来更多最初主要是在本地部署的 Windows 客户，

来考虑，如果我们甚至正在关注 Linux，那么我们如何让他们关注 Azure 中的 Linux 呢？所以这有点像我们向高层管理人员推销的东西，他们同意，“嘿，这很有意义。除了时间和精力之外，我们不会失去任何东西。”所以随着时间的推移，你知道，我们做了很多这样的工作。我们以 Azure PowerShell 为目标，作为一种方式，你知道，如果你对对象很熟悉，你可以在 Linux 上的 PowerShell 中使用 Azure PowerShell 来有效地管理你的 Azure 资源。

早期，我不知道是否每个人都知道这一点，但在我们真正公开宣布转向跨平台开源之前，我们实际上与 VMware、谷歌计算云以及 AWS 进行了交谈，他们都同意了，因为他们也有 Windows cmdlet，对吧？让他们说，“嘿……”

这是戴着我的开源帽子而不是我的 Windows 帽子。它就像，“嘿，我们也希望这在我们的 Windows 上得到支持。”他们都加入了进来。所以我们最初对 Linux 用户的提议是，你可以使用 PowerShell，学习 PowerShell，你可以管理不同的云。它与之无关，你获得了对象的优势。所以随着时间的推移，我们继续发展它。显然，我们是微软的员工，所以我们确实会优先考虑 Azure，但不是只考虑 Azure。

你拥有的 RFC 流程意味着路线图也是公开的吗？是也不是。所以 RFC 指的是征求意见，对吧？它就像我们想要一个更正式的过程，关于团队如何工作

展示未来的工作，例如技术设计，以及我们试图瞄准的场景等等，但也允许社区，如果他们想提出一个功能，我们让他们更多地思考它的一些影响，而不是仅仅打开一个问题并抱怨我们为什么还没有做到，对吧？所以我们很久以前就创建了 RFC 流程，结果证明，需要明确的是，我们在开源中做的很多事情，我们并没有发明。我们没有

我们是第一个在这里开辟新天地的人。我们总是试图关注其他团队。例如，我们关注 .NET。他们已经做了很多。他们是一个更大的团队。我们试图向他们学习，避免陷阱等等。但我们从早期拥有的 RFC 流程中学到的一件事是，它太繁重了。

对于团队来说，审查这些东西很繁重。对于我们的社区来说，编写这些东西也很繁重。所以我们实际上在过去两年里修改了它。我们只是在 GitHub 上开始一个问题或讨论，并说，“嘿，你有一个想法。把它贴在那里。不要只考虑我们所说的彩虹、阳光明媚的路径，一切都能正常工作。考虑一下当它不工作时会发生什么。你如何通知用户？体验是什么样的？诸如此类的事情。然后我们现在也有工作组的概念。

这几乎有一半甚至更多的是由社区成员担任工作组成员来完成的。因此，现在我们不再只有一个委员会（我是其中一员）来做出所有这些高级别的决策，我们实际上有更专业的组，他们会说：“嘿，你们是引擎的工作组，这里有一些社区提出的问题，它有意义吗？比如，它与我们对PowerShell引擎的期望一致吗？”我们还有一个负责命令列表的工作组，例如，“好吧，它是否遵循最佳实践？”

1 我们需要回退并说，也许它不属于PowerShell的命令，而应该是一个单独的模块，由某人发布到库中。我们不需要将整个宇宙都包含在一个项目中。我们有库是有原因的，这样人们就可以发布内容，人们也可以选择自己想要的内容。

2 所以这就是我们今天的现状。我认为它运行得相当好。需要记住的是，我没有一个庞大的团队来管理这个相当大的项目。因此，我们必须选择我们的战斗，并不断发展，看看我们如何在团队内部以及通过社区来提高效率和效力。我再举个例子，随着我的工作范围扩大，某些事情开始优先于纯粹的PowerShell项目，我不得不转移资源，

3 但由此产生的副作用之一是，社区没有像项目刚开始时那样看到我们在我们的代码库上活跃。他们对此相当不满。因此，我们所做的一件事是，我们团队的星期一变成了社区日。因此，对于OpenSSH项目，该项目的成员将专注于社区事务。社区事务是指响应问题、查看社区的PR，甚至修复问题等等。

4 我从这个模式中看到了两个主要好处。一是团队中的每个人都知道，我们将把星期一专门用于此。因此，每个人都看到彼此在处理这些事情，对吧？对于社区来说，他们现在有一个规律的节奏。他们可以期待地说，“嘿，你知道吗，我提出了这个问题。你很久没回应了。这是什么意思？”现在，他们至少知道他们有可能在星期一得到答复，对吧？所以这就是我们如何做的，而且效果相当好。这并不意味着团队成员不能在周中查看社区事务。只是说星期一会有重点。

5 显然，我们还做了一些不公开的事情，这些事情最终会公开，但可能不是开源的。我们在Azure内部、在Azure合作伙伴内部做的一些事情，我们不会透露他们的功能，因为我们正在与他们合作。我们把它留给他们。所以一周中的其他日子会占用这种工作，对吧？所以……

6 未来会怎样？因为PowerShell做了很多事情。你可以在远程机器上使用它。有一个用于嵌入它的托管API。甚至还有配置即代码。所有这些如何融合在一起？未来的愿景是什么？事情将走向何方？

7 所以我要在这里做个宣传。如果你访问aka.ms/psblog，我尝试做的一件事是作为公共路线图的一部分，我会尽早发布一篇博文。我认为我在今年一月做到了。那很好。去年，我认为时间更长，这就像只是概述我们全年的投资一样。显然，我在博客中发布的内容并非承诺。这是我们正在努力实现的目标，并非所有目标都能实现。

8 原因有很多。有些事情结果比预期的要复杂得多，等等。无论如何，我已经把它发布出来了，但我只想总结一下。比如，我们一直在关注PowerShell的一件事是认识到并非每个人都会编写cmdlet，对吧？这就像与PowerShell交互的所谓的原生方式是编写cmdlet。因此，您可以获得一致性、发现构建，所有这些好东西。但是有很多原生命令，我们称之为原生命令，比如kubectl、Docker，你知道的，人们使用的那些东西，例如Git。

9 Git不是，我的意思是，其中一些项目确实有团队在围绕它们构建社区命令。但我也要说，有很多工具没有人会去做，因为这样做没有意义，或者它们正在积极开发中，你总是会在追赶，对吧？要创建一个底层代码只是调用原生命令的cmdlet等效项，这只会调用原生命令。

10 因此，我们一直在研究的很多事情是如何使PowerShell成为非cmdlet的优秀shell，对吧？我认为cmdlet的情况是所谓的已解决。所以问题是，我们如何确保对于任何只是将其用作shell的人来说，它都能按照他们期望的方式工作？例如，如果他们去Stack Overflow并找到一个kubectl命令示例，如果他们在PowerShell中粘贴它，它是否会工作？在某些情况下它不会，因为解析方式不同，我们不会改变这一点，因为那样会破坏其他场景。

11 但我们现在正在研究的一些东西是，例如，我们如何使非PowerShell命令更容易注册参数补全器？Azure CLI就是一个例子。它也是由微软拥有的。但实际上，有大量的人希望在PowerShell中使用Azure CLI作为他们选择与Azure交互的方式。

12 而许多Azure PowerShell用户则使用它来编写脚本和进行自动化。虽然看起来是一者或另一者，但很多人实际上同时使用两者。他们一直在努力的一件事是在PowerShell中为Azure CLI提供此参数补全器。他们提出的一个问题是，我们如何注册这个东西？我们一直在努力解决其中的一些问题。

13 我在博客文章中提到的另一个例子是，有很多命令，包括Docker、Qt Control等等，它们实际上输出JSON或有一种输出JSON的方法。同样，JSON不是一个活动对象，但它是结构化数据。因此，在今天的PowerShell中，如果您是……

14 中级用户，您会知道，“我将运行这个复杂的命令，它将输出JSON。我可以将其管道传输到convert from JSON，我可以得到一个看起来像PowerShell中另一个对象的object，对吧？”所以我们正在研究的一件事是，“在某些有意义的用例中，我们如何自动化这个过程？如果我们知道命令将输出JSON，是否可以代表用户自动转换它，这样他们就不必担心在中间插入convert from JSON了，诸如此类。所以我希望有一个RFC规范

15 它不会在二月发布，因为我们快完成了。也许下个月才能概述它究竟是如何工作的，对吧？那里的想法实际上也不是要拥有PowerShell专有的想法，而是可以被其他shell采用的东西，对吧？这样我们就可以鼓励整个生态系统说，“猜猜看？JSON在shell中是有意义的。我认为这场战斗已经打赢了，对吧？我不是JSON的忠实粉丝，但我可以接受这一点

16 每种语言都有JSON的工具。让我们同意坚持使用它。我们可以通过让工具发出它并让shell能够理解它来使整个生态系统更好，对吧？所以这是我们在7.4版本（今年的日历年）中关注的一个重要领域，如何使它更自然，以便您可以拥有可以参与对象方面而不仅仅是文本的命令。

17 还有很多其他的事情，但这正是我一直在关注的一件大事。实际上，我要提到的另一件大事是，每个人都可能看到了Bing和ChatGPT的集成。因此，人工智能绝对是每个人都在关注的事情。这是我们实际上已经关注了一段时间的事情。我不确定每个人是否都知道，但在ChatGPT之前，甚至在其他一些流行的工具出现之前，比如Stable Diffusion等等，我们几年前就在研究人工智能，当时这些技术还没有准备好。我们实际上有一个插件模型。因此，PS Reliant是我们用来为PowerShell用户提供交互式体验的方式的模块。因此，我们在7.1版本中做的一件事，我认为大概是两三年前，是添加了一个预测器插件。因此，有人可以实际使用C#构建一个预测器，并能够通过PS Reliant将其呈现给用户，对吧？我们与Azure PowerShell合作的主要合作伙伴，因为他们实际上有一个

18 一个做神经网络的团队，有模型训练等等。那里的想法是，当你输入时，这类似于你可能在GitHub Copilot中看到的情况，当你输入一个AZ PowerShell命令时，我们知道你正在尝试创建一个虚拟机，例如，然后我们可以预测填写一些参数值。也许我们知道你在美国东海岸，美国东部，或者也许你之前定义了一个名为XYZ的变量，你想使用它。这已经存在了，而且非常有限。

19 但现在我们正在与其他一些合作伙伴合作，说：“嘿，在控制台中还有什么其他有趣的情景可以让人工智能帮助人们提高生产力？”我知道社区……我们在上个月的Poshel社区电话会议上对此进行了演示，我们每个月的第三个星期四都会举行。Doug Fink是社区成员之一，他对此进行了演示。所以基本上他编写了一个Poshel模块，它可以直接与ChatGPT一起工作。所以在Poshel控制台中，你可以用自然语言向它提问。

20 它将返回结果，你可以接受或不接受它。顺便说一句，我要说的是，今天人工智能产生的任何东西，你都应该在接受并按下回车键之前进行审查，因为谁知道会发生什么。这也适用于Copilot。Copilot将预测代码。你应该始终审查即将出现的内容，而不仅仅是签入。但这些都是很好的加速器，对吧？它可以告诉你一些你没有想过或不知道的事情，你可以决定如何最好地为自己使用它。所以这些是我们正在研究的一些场景。

21 是如何最好地不仅集成人工智能，而且如何让合作伙伴和其他第三方参与并这样做，所以我们正在将这些插件公开，然后希望其他公司和机构构建在PowerShell生态系统中工作的插件。在我们结束之前，我有两个闪电般的问题要问你。当然。你目前正在玩哪些有趣的工具，可能是开发工具？

22 脱口而出，我必须说，回到ChatGPT，我一直在做这方面的实验，再次看看它如何有用以及如何集成它，以便获得更自然的体验。说得对。然后第二个问题是，你目前的科技设置是什么？你每天使用什么硬件和软件？我的主要开发机器实际上是M1 MacBook Pro。

23 不幸的是，微软没有预算让我升级到新的M2系统。我有一台MacBook的原因之一……实际上，我之前的开发系统主要是一台MacBook Pro x64机器。当我们第一次开始跨平台开源项目时，

24 你可以获得Linux虚拟机和容器，但你无法虚拟化Mac OS，至少在法律上不行。因此，为了涵盖我们的测试，一些团队成员拥有MacBook是有意义的，因为现在我们实际上可以在上面进行开发。我们可以测试它等等。所以我最终得到了一台这样的笔记本电脑，我一直都在使用它。顺便说一句，我家里还有一台Windows Surface Pro X。所以我可以在这两台机器上进行开发。我可以使用Windows子系统Linux来处理Linux相关的事情，对吧？我确实有所有这些机器可供自己使用，这对我来说是有益的，但是……

25 我的主要机器是一台MacBook Pro，我大部分工作都在上面完成，然后当我需要做Windows特定的事情时，我就远程桌面连接到我的Windows机器。我在两个系统上都使用Visual Studio Code作为我的主要IDE。酷。非常好。不幸的是，这就是我们今天的时间。感谢你的加入，Steve。

26 当然。这很有趣。我已经为其他PowerShell特定的事情做过这些事情，所以我认为对我来说，扩展分支并不会进行非常PowerShell特定的焦点讨论，这很有趣。虽然我的讨论是关于PowerShell的，但与一个不是PowerShell的群体进行讨论。

27 感谢收听Console DevTools播客。请在Twitter上告诉我们你的想法。我的Twitter是David Mitton，你也可以关注console.dev。不要忘记订阅并在你的播客播放器中给我们评分。如果你正在玩弄或构建任何有趣的DevTools，请与我们联系。我们的电子邮件在节目说明中。下次再见。