On Sat, 10 May 2003 17:50:55 +0900, Brian Candler wrote: > I don't use Windows either, but Windows does support processes with pipes > between them, based on what I've seen posted here. It works as well as you > can expect any O.S. feature in Windows to work :-) In rubys source for "io.c" there is a bunch of WIN32 checks > grep WIN32 io.c #if defined(MSDOS) || defined(__BOW__) || defined(__CYGWIN__) || defined(_WIN32) || defined(__human68k__) || defined(__EMX__) || defined(__BEOS__) #if defined(MSDOS) || defined(__CYGWIN__) || defined(_WIN32) #if !defined(DJGPP) && !defined(_WIN32) && !defined(__human68k__) #if defined(HAVE_FCNTL_H) || defined(_WIN32) #if defined(_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__EMX__) #if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__VMS) #if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) || defined(__VMS) #if !defined (__CYGWIN__) && !defined(_WIN32) #ifdef _WIN32 #ifdef _WIN32 #if defined (_WIN32) || defined(DJGPP) || defined(__CYGWIN__) || defined(__human68k__) > The first 4 of them seems OK.. the rest of them is where I see that windows requirs special attention. Windows is wierd. >> ruby-in-a-sandbox: Im working on editor project where I "think" I need >> this feature (my knowledge about unix-TTYs is minimal). > > And you need it because you want the vim-like feature: "run this program and > capture its output into the editor buffer"? No. My rationale for using ruby-sandbox is that many applications gets started from the desktop (not the console). Thus thier output is hidden. I have to get comfortable with this feature, before I can tell if its a good or a bad feature. Further more I want to be able to run my favorite ruby-scripts unmodified. Example: rubyunit outputs to stdout/stderr. I don't want to make changes to their source. Because its a feature I need myself, then I assume that many people would have interest in this. Im just following my very bad intuition :-) > My argument is that the capturing belongs at the point where you run the > external program, just as if you were writing your code in C++ directly, not > in some framework where you have to jump through hoops with pipes and > threads (which are dangerous here) I want to give people this choise, between the blue or the red pill :-) > How about adding a FAQ to your tutorial? Here's one I contribute. Thanks.. This is a good Q&A, I will add it. > A. If you don't mind mixing the child's stdout and stderr, you might just > get away with using shell redirection: > string = `someprog args 2>&1` This is the answer I have bumped into most-frequently on google. BTW: isn't this kind of redirection shell-specific (tcsh, zsh, ksh). I just saw your RCR.. nice http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/71107 [snip a short working example] [snip the reverse parallel] Great contribution.. I will certainly add it :-) > If you were writing your editor entirely in C++, or entirely in Ruby for > that matter, you'd have the same issue. So this isn't really anything > specific to embedding Ruby. Yes, this is not specific to ruby. > On a different point, I hope that catching exceptions is an area you have > covered or will cover in the tutorial? I have a section about this: It covers how * catching ruby exceptions and translating them into c++ exceptions (with full backtrace). * catching c++ exceptions and translating them into ruby exceptions (no backtrace). Look at the "Exception Handling" section and tell me what you think: http://metaeditor.sf.net/embed/ -- Simon Strandgaard