system() 从脚本/控制台调用成功，但在应用程序中默默失败
具体调用 gpg。
我很难追踪问题，因为日志没有为这些失败的调用提供任何输出，并且它们在生产控制台中完美运行。
我尝试指定 gpg: 的路径
system "path/to/gpg --all -my --encryption -options
，并确保 Passenger 在我进入控制台的同一用户下运行。我还尝试过对命令进行反引号和 %x() 操作以寻找更详细的响应。
运气不好。事实证明，祈祷、舞蹈和暴力同样毫无用处。
Specifically calls to gpg.
I'm having a hard time tracking down the problem as the logs don't give any output for these failing calls and they work perfectly from the production console.
I've tried specifying the path to gpg:
system "path/to/gpg --all -my --encryption -options
and have made sure that Passenger is running under the same user that I am entering the console as. I've also tried backticking and %x()ing the commands in search of a more verbose response.
No luck. Prayer, dance and violence have proved equally useless.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了帮助调试此类问题，您可以尝试调用处理问题日志记录的 bash 脚本，而不是直接使用命令：
然后从 ruby 调用
system "my_gpg_script.sh"。To help debug issues like this, you could try calling a bash script which handles logging of issues, instead of the command directly:
Then call
system "my_gpg_script.sh"from ruby.Lebreeze 让我走上了正确的道路，但我永远无法让 STDOUT 重定向到我的日志，最终不得不通过跟踪整个方法进行调试，如这里建议的 https://serverfault.com/questions/98994/suppress-gpg-reading-passphrase-from-file-descriptor-0-message
原来是路径问题。我天真地认为只要环境和用户相同，$PATH 在控制台和应用程序中就会相同。事实并非如此。不过，在我的 httpd.conf 文件中添加一些额外的路径解决了我的问题。
Lebreeze got me on the right path, but I could never get the STDOUT to redirect to my log and ended up having to debug by tracing the whole method as suggested over here https://serverfault.com/questions/98994/suppress-gpg-reading-passphrase-from-file-descriptor-0-message
It turned out to be a path issue. I had naively thought that $PATH would be the same in the console and application as long as the environment and user were the same. Not the case. Adding some extra paths in my httpd.conf file fixed me up though.