Files项目中的PowerShell脚本执行工作目录问题解析

在Windows文件管理工具Files（版本3.9.1.0）中，用户报告了一个关于PowerShell脚本执行时工作目录设置的问题。当用户通过Files的"使用PowerShell运行"功能执行脚本时，系统默认将工作目录设置为C:\WINDOWS\System32，而不是脚本所在目录，这导致了依赖相对路径的脚本执行失败。

问题现象

用户创建了一个简单的PowerShell脚本build.ps1，内容为执行一个基于相对路径的dotnet命令：

dotnet run --project build/Build.csproj
exit $LASTEXITCODE;

当通过Windows资源管理器的"使用PowerShell运行"功能执行时，脚本能够正常工作。但在Files应用中执行同样的操作时，却出现了找不到项目的错误，因为工作目录被错误地设置为系统目录而非脚本所在目录。

技术分析

这个问题源于Files应用在调用PowerShell进程时，没有正确设置工作目录。在Windows系统中，当执行脚本时，通常应该将工作目录设置为脚本所在目录，这是符合用户预期的行为。

PowerShell提供了一个内置变量$PSScriptRoot，可以获取当前执行脚本的目录路径。用户可以通过在脚本开头添加Set-Location -Path $PSScriptRoot来手动设置工作目录，但这只是一个临时解决方案。

解决方案

Files开发团队已经确认这是一个需要修复的问题。他们计划在代码中修改PowerShell进程创建逻辑，增加对工作目录的支持。具体实现方式可能包括：

1. 扩展CreatePowershellProcess方法，增加可选的工作目录参数
2. 在调用该方法时，自动将脚本所在目录作为工作目录传递
3. 保持向后兼容性，不影响现有代码的功能

这种修改将确保通过Files执行的PowerShell脚本与通过资源管理器执行的行为一致，都使用脚本所在目录作为工作目录。

临时解决方案

在官方修复发布前，用户可以采取以下临时解决方案：

1. 在脚本开头显式设置工作目录：

   Set-Location -Path $PSScriptRoot
   

2. 创建脚本的快捷方式，并确保快捷方式的"起始位置"属性为空

3. 使用绝对路径替代相对路径

总结

这个问题的出现提醒我们，在开发跨平台或替代系统工具的应用时，需要特别注意保持与系统原生工具行为的一致性。Files团队对此问题的快速响应和修复计划，展示了他们对用户体验的重视。对于依赖PowerShell脚本自动化的用户，建议关注Files的后续更新，以获取这个问题的官方修复。