PowerShell 6.0 的已知问题Known Issues for PowerShell 6.0

注意：由于许多基础子系统的相似性，Linux 和 macOS 上的 PowerShell 倾向于在功能和 bug 方面共享相同的成熟度级别。除下文所述，本部分中的问题将适用于这两个操作系统。

PowerShell 中的区分大小写Case-sensitivity in PowerShell

PowerShell 一直以来均区分大小写，只有少数例外情况。在类似于 UNIX 的操作系统上，文件系统基本都区分大小写，并且 PowerShell 遵守文件系统的标准；这通过多种方式显示，明显和非明显的方式。

直接Directly

在 PowerShell 中指定一个文件时，必须使用正确的大小写。

间接Indirectly

如果文件名大小写有误，则 Tab 自动补全将不会自动完成。要完成的片段必须采用正确的大小写。（对于类型名称和类型成员完成，完成是不区分大小写的。）

.PS1 文件扩展名.PS1 File Extensions

PowerShell 脚本必须以结尾，以便解释器了解如何在当前进程中加载并运行它们。在当前进程中运行脚本是 PowerShell 的预期常见行为。可能会将 #! 幻数添加到不带 .ps1 扩展名的脚本，但这将导致该脚本在新的 PowerShell 实例中运行，从而在交换对象时阻止脚本正常运行。（注意：这可能是从 bash 或其他 shell 执行 PowerShell 脚本时所期望的行为。）

缺少命令别名Missing command aliases

在 Linux/macOS 上，已删除基本命令 ls、cp、mv、rm、cat、man、mount、ps 的“方便别名”。在 Windows 上，为了方便用户，PowerShell 提供一组映射到 Linux 命令名的别名。已从 Linux/macOS 分发上的默认 PowerShell 中删除这些别名，以允许在不指定路径的情况下运行本机可执行文件。

执行此操作既有优点，又有缺点。删除别名会向 PowerShell 用户公开本机命令体验，但会降低 shell 中的功能，因为本机命令会返回字符串，而不是对象。

备注

PowerShell 团队正在寻求此方面的反馈。首选解决方案是什么？我们应保持原样还是重新添加方便别名？请参阅问题 #929。

目前，PowerShell 只对 Windows 上的内置 cmdlet 和 Linux 上的外部命令或二进制文件及 cmdlet 做通配符扩展（通配）。这意味着，类似 ls .txt 的命令将失败，因为不会展开星号以匹配文件名。可以通过执行 ls (gci .txt | % name) ，或更简单地使用等效于 ls 的 PowerShell 内置项来执行 gci *.txt 以解决此问题。

.NET Framework 和 .NET Core Framework.NET Framework vs .NET Core Framework

Linux/macOS 上的 PowerShell 使用 .NET Core，即 Microsoft Windows 上的完整 .NET Framework 的子集。这非常重要，因为 PowerShell 提供对基础框架类型、方法等的直接访问。因此，在 Windows 上运行的脚本可能无法在非 Windows 平台上运行，因为框架之间存在差异。有关 .NET Core Framework 的详细信息，请参阅 https://dotnetfoundation.org/net-core

随着的出现，.NET Core 2.0 将恢复存在于完整 .NET Framework 中的许多传统类型和方法。这意味着，PowerShell Core 将能够加载许多传统 Windows PowerShell 模块，而无需进行修改。可以在此处了解我们有关 .NET Standard 2.0 的工作。

重定向问题Redirection Issues

任何平台上的 PowerShell 中均不支持输入重定向。问题 #1629

使用 Get-Content 将文件内容写入管道。

在使用默认的 UTF-8 编码时，重定向的输出将包含 Unicode 字节顺序标记 (BOM)。在使用不应包含 BOM 的实用工具或附加到文件时，BOM 将导致出现问题。使用写入 ASCII 文本（它不是 Unicode，将不包含 BOM）。

备注

请参阅，向我们提供有关在所有平台上改进 PowerShell Core 编码体验的反馈。我们致力于支持不带 BOM 的 UTF-8，以及可能不断变化的各种跨平台的 cmdlet 的编码默认值。

作业控制Job Control

Linux/macOS 上的 PowerShell 中不支持作业控制。fg 和 bg 命令不可用。

目前，PowerShell Core 支持在 macOS 和 Linux 上经过基本身份验证以及在 Linux 上经过基于 NTLM 的身份验证的通过 WSMan 的 PowerShell 远程处理 (PSRP)。（不支持基于 Kerberos 的身份验证。）

在存储库中完成基于 WSMan 的远程处理工作。

PowerShell Core 还支持所有平台（Windows、macOS 和 Linux）上通过 SSH 的 PowerShell 远程处理 (PSRP)。虽然目前在生产中不支持此功能，但可以在此处了解有关此设置的详细信息。

Just-Enough-Administration (JEA) 支持Just-Enough-Administration (JEA) Support

Linux/macOS 上的 PowerShell 目前无法创建约束管理 (JEA) 远程处理终结点。此功能目前不在 6.0 的范围内，我们将在后 6.0 中考虑此功能，因为它需要大量的设计工作。

sudo、exec 和 PowerShellsudo, exec, and PowerShell

由于 PowerShell 在内存（如 Python 或 Ruby）中运行大多数命令，不能直接将 sudo 与 PowerShell 内置项一起使用。（当然，可以从 sudo 运行 pwsh。）如果需要使用 sudo（例如，sudo Set-Date 8/18/2016）从 PowerShell 内运行 PowerShell cmdlet，则要执行 sudo pwsh Set-Date 8/18/2016。同样，不能直接执行 PowerShell 内置项。而必须执行 exec pwsh item_to_exec。

此问题目前作为的一部分进行跟踪。

缺少 CmdletMissing Cmdlets

通常可用于 PowerShell 的大多数命令 (cmdlet) 在 Linux/macOS 上不可用。在许多情况下，这些命令在这些平台（例如，类似于注册表的 Windows 特定的功能）上没有意义。类似于服务控制命令 (Get/Start/Stop-Service) 的其他命令存在，但不起作用。将来的版本将纠正这些问题，修复损坏的 cmdlet 并随着事件的推移添加一些新的 cmdlet。

下表列出了 Linux/macOS 上的 PowerShell 中已知不起作用的命令。

PowerShell Core 6.0 中的已知问题