我在 Ubuntu 20.04 上编译了最新的 gnu 编译器（11.2）。在我的~/.bashrc 中，我安装了 gcc/g++ 的目录被路径化了。
现在，我已经使用 gcc 11.2 编译器在 wsl2 中编译了 R。然后我安装了 Rstudio（R 统计语言的 IDE）。安装后，我可以从 Windows 11 开始菜单运行使用我编译的 R 的 Rstudio。太棒了！
但是，当通过从 Win11 开始菜单启动的 Rstudio 调用 R 本身时，它并没有获取我在 ~/.bashrc 中设置的路径。
这意味着，R 控制台环境中没有编译器路径，这些路径在我的 .bashrc 中。在 R 中编译包时，它使用与构建 R 本身相同的标志。因此，如果 R 控制台环境中没有 gcc11.2，R 就无法调用 gcc 11.2 来编译任何包！这是一个大问题。我在 /etc/wsl.conf 中将默认用户设置为我，如果我从 R 控制台检查系统环境，我可以看到，当从 Win11 开始菜单启动时，我被正确设置为用户。
如果我在 Rstudio 中打开系统终端，它也会以我的用户帐户运行，但它会处理 ~/.bashrc，一切正常。但重要的是，终端运行的环境与 R 控制台不同。
很明显，从 Win11 开始菜单执行时，R 控制台似乎没有获得 post-bashrc 环境。从 win11 开始菜单启动 Rstudio 时，它会获得一个基本环境。
如果我启动默认为我的用户帐户的 WSL.EXE，然后从那里启动 Rstudio，R 控制台就会获得正确的路径。是的。编译包成功了。所以我想我可以这样做……但我希望它简洁，并且只需从开始菜单就可以完成所有操作。
那么，从 Win11 开始菜单启动的 Linux 应用程序从哪里获取其环境变量？我如何附加或仅使用 ~/.bashrc 中的 $PATH？
非常感谢K
答案1
这看起来与我在这个 Stack Overflow 上的答案，只是wsl.exe我们现在处理的不是wslg.exe。
总而言之，当您通过 Windows 中的“开始”菜单启动 Linux GUI 应用程序时，它会使用通过以下方式调用该应用程序的快捷方式：
wslg.exe ~ -d <distroname> <app> <arguments>
与wsl.exe命令一样，wslg.exe启动 shell（并且它做首先启动 shell）作为非登录、非交互 shell。这意味着在使用“开始”菜单快捷方式启动时，不会处理~/.bashrc和。~/.bash_profile
解决方案类似——通过以下方式编辑快捷方式：
在“开始”菜单中右键单击 Linux 应用程序
选择打开文件所在位置
右键点击...-> 中相应的快捷方式开始菜单->程式->文件夹。
选择特性
更改目标从：
C:\Windows\System32\wslg.exe ~ -d <distroname> <app> <arguments>到 ...
C:\Windows\System32\wslg.exe ~ -d <distroname> bash -ilc <app> <arguments>
附注 #1：从技术上讲，最好将PATH调整放在~/.bash_profile并指定中，bash -lc而不是bash -ilc。这样您就可以（如果需要的话，将来）执行交互的中的命令~/.bashrc。例如，我在交互式会话中启动keychain（ssh-agent管理器），它通过密码提示解锁指定的 SSH 密钥。这种交互式命令将无法wslg.exe启动，因为它不会启动终端/交互式会话。
如果你曾经做向你的 中添加一些交互内容~/.bashrc，这会破坏此“开始菜单”调整，如果不进行额外研究，你可能记不住原因。最好现在就“做对”，并防止将来出现潜在问题。
附注 #2（供我自己将来参考以及任何有此wsl.exe命令经验的人参考）-- 该wslg.exe命令（奇怪的是）确实不是似乎支持-e直接启动到 shell 的标志。这意味着在这种情况下，您实际上将执行两次 shell —— 第一次执行将wslg.exe启动您的默认 shell（同样，作为非登录、非交互式 shell），然后您的默认 shell（可能是 bash）将转而启动另一个bash作为交互式登录 shell。