G-WAN何去何从?

Question

G-WAN上的stderr在哪里，例如，如果我有以下ruby脚本:

require 'time'
START_TIME = Time.now    
ENV.each do |k,v|
  puts "#{k} => #{v} <br/>"
end   
RUNTIME = Time.now - START_TIME
puts "<br/>%.2f ms" % (RUNTIME*1000.0)
$stderr.puts "Test 123"
exit(200)

当脚本请求时，logs/*目录或控制台中没有Test 123字符串

Answer 1

G-WAN上的错误在哪里?

如果我没记错的话，stdin, strerr和stdout是在守护模式下关闭的，因为它们无论如何都是不可访问的，因为G-WAN从它的父终端分离了。

但是在"交互"模式下，G-WAN仍然显示控制台输出，如编译错误和"优雅"崩溃报告(servlet崩溃而不是崩溃服务器)，这些文件描述符被打开。

这可以很容易地从任何G-WAN使用脚本加载为模块(C, C++, C#, Java, PH7, Objective-C等)检查，也就是说，当脚本共享G-WAN内存空间。

但是当使用CGI进程时，因为脚本运行时没有作为模块加载(Ruby, Perl等)，这与G-WAN运行外部进程和管道stdout不同。

在后一种情况下，G-WAN将需要另一个管道来传输stderr。没有这样做，这就是为什么当从Ruby脚本将输出定向到stderr时看不到任何内容的原因。

使用更多的管道将消耗更多的文件描述符，并且在服务器负载下速度更快，因此，除非您对该特性有一个值得与我们分享的引人注目的用途，否则实现它可能没有多大意义。

最终，所有脚本语言都应该使用在G-WAN内存空间中加载的模块，因为这允许更高的性能和并发性。

因此，G-WAN可以使用stderr而无需额外的Ruby成本，这只是时间问题(以及Ruby社区的帮助)。