22H2 更新后不久,我打开 WSL 在我的 Ubuntu 环境中设置了一个 @reboot cron 任务。WSL 打开没有任何问题。
我想从 PowerShell 重新启动 WSL,以确保我的 crontab 更改有效,结果如下:
不过,这并没有让我慢下来,因为老好的 cmd.exe 很乐意地满足了我的要求。这让我想知道命令wsl
在哪里。
我还没有找到一个明确的方法来解决这个问题,但是从我所发现的情况来看,我猜测问题与 PowerShell 偏爱 64 位代码而不是 32 位代码有关......也许它甚至不想在旧的 Windows\System32 目录中查找任何东西?
我的系统路径包括%SystemRoot%\System32
,并且我没有看到任何迹象表明 PowerShell 现在使用不同的命令路径,所以我不确定如何解决这个问题。
更新:
即使使用 wsl 命令的完整路径也无济于事。看来 PowerShell 现在只是对执行此命令说“不”。
不,卸载 WSL 并重新安装它没有帮助。
答案1
您实际上对 32 位与 64 位有一个很好的想法,这让我走上了正确的轨道,只是……倒退了!
从评论中,我们确定正在运行的是 32 位版本的 PowerShell。显然,这只是将错误的 PowerShell 版本固定在任务栏上的情况。
实际上可以从 32 位应用程序运行 64 位应用程序(如 WSL),但你需要使用:
C:\Windows\sysnative\wsl.exe
这就是(在评论中)告诉我们的,这确实曾是导致此问题的 32 位 PowerShell。我在其他 Stack Exchange 问题中看到过在使用其他 32 位终端应用程序时发生这种情况(Hyper.JS IIRC)。
当然,正确的解决方案是使用 64 位 PowerShell,在我们找到根本原因后,您肯定可以自己找到这个解决方案。