为什么可以在重新启动后找到“ raku”二进制文件?
我的测试是我从GitHub下载的Raku发行版中在逗号中运行的测试。
测试昨晚通过了。但是今天早上重新启动后,测试不再通过。该测试在计算机上运行raku
。经过一番调查,我发现,二进制没有在测试中找到:
say(运行''','raku',:out).out.slurp; #无需输出
,但是如果我从命令行直接使用prove6运行测试,我将获得通往raku的完整路径。
我正在使用rakubrew。
我可以通过在测试中添加完整的路径来轻松解决此问题,但是我很想知道为什么Comma Ide Sudddenly找不到通往Raku二进制的路径。
更新:我也应该提到我今天早上重新介绍了Proejct,这引起了一些问题,因此我使缓存无效。因此,可能是导致问题的重新启动,而不是重新启动。我不确定。
更新2:毫不奇怪,但是
我的$ raku-path =(shell'echo $ path',:out).out.slurp;
仅产生/usr/ bin:/bin:/usr/sbin:/sbin
I have a test that I'm running in Comma IDE from a Raku distro downloaded from github.
The tests passed last night. But after rebooting this morning, the test no longer passes. The test runs the raku
on the machine. After some investigation, I discovered, that the binary was not getting found in the test:
say (run 'which', 'raku', :out).out.slurp; # outputs nothing
But if I run the test directly with prove6 from the command line, I get the full path to raku.
I'm using rakubrew.
I can easily fix this by adding the full path in the test, but I'm curious to know why Comma IDE sudddenly can't find the path to the raku binary.
UPDATE: I should also mention I reimported the proejct this morning and that caused some problems so I invalidated caches. So it may have been this and not the reboot that caused the problem. I'm unsure.
UPDATE 2: No surprise but
my $raku-path = (shell 'echo $PATH', :out).out.slurp;
yields only /usr/bin:/bin:/usr/sbin:/sbin
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我最好的猜测是:在奏效的情况下,逗号是从Rakubrew建立环境的外壳开始的。然后,重新启动后,逗号再次启动,但是从事实并非如此。
除非您选择这样做,否则环境变量将从父过程传递到子进程。逗号从启动它的过程中继承了那些,这些过程将传递到逗号产生的任何raku过程中。您的选项:
$*可执行
而不是raku
(此变量符合当前执行的Raku实现的途径),My best guess: in the situation where it worked, Comma was started from a shell where rakubrew had set up the environment. Then, after the reboot, Comma was started again, but from a shell where that was not the case.
Unless you choose to do otherwise, environment variables are passed on from parent process to child process. Comma inherits those from the process that starts it, and those are passed on to any Raku process that is spawned from Comma. Your options:
$*EXECUTABLE
instead ofwhich raku
(this variable holds the path to the currently executing Raku implementation)