> I have a question on your test suite.
> Would backticks not be more portable then trying to figure out how to
> redirect STDOUT on each OS? To me, it would just be simpler to use the
No, I don't need to "figure out", I just execute a
perl -e ".....redirections...;system '$command'";
where redirections is a series of
close FH / open FH1, ">&FH2" / open FH, "file";
( the is_win32() ? "NUL:" : "/dev/null"; is the *only*
part that needs "figuring out", and can be ( at will )
substituted by and "open FH, "> junkfile_since_we_dont_have_devnull";
> --ouput flag of the assembler to create the .pbc file, and then use
> backticks to capture the output of the interpreter.
Well, in the case of the assembler output flag, yes, but the problem
is really STDERR [1], that is not captured by backticks. Now that I
think of it, IPC::Open3 might do the trick nicely, but looking at
his page I fear that it could actually be more difficult than it
seems [2], so I'll just stick with this ( unless someone has
better ideas, of course )
Regards
Mattia
[1] from perldoc perlop
Because backticks do not affect standard error, use shell file
descriptor syntax (assuming the shell supports this) if you care to
address this. To capture a command's STDERR and STDOUT together:
[2] from perldoc IPC::Open3
If you try to read from the child's stdout writer and their stderr
writer, you'll have problems with blocking, which means you'll want
to use {HYPERLINK "../../lib/Pod/perlfunc.html" \l
"item_select"}select() or the IO::Select, which means you'd best use
{HYPERLINK "../../lib/Pod/perlfunc.html" \l "item_sysread"}sysread()
instead of {HYPERLINK "../../lib/Pod/perlfunc.html" \l
"item_readline"}readline() for normal stuff.
