Comments on: Input and Output Redirection in REBOL
Ok, let's talk about file redirection and how REBOL should operate when it is given redirected input and output files. This is a traditional area of difficulty for most software products that run interactively but need to behave in a standard way when redirection is used (non-interactively). REBOL is no exception (in fact right now, unfortunately, you can easily cause it to crash. But, that's being fixed today.)
For those of you who are new to input/output redirection, on most Unix-like systems redirection is often done at the shell level with command lines that use arrows or bars (of course, that's just how it's done in a shell - it can also be done at the process level), such as:
rebol code.r >outfile.txt rebol code.r <infile.txt >outfile.txt ls | rebol sort.r ls .. | rebol sort.r | more
Where code.r and sort.r are REBOL programs that read from the input stream. For example, the sort.r program might be as simple as:
data:  while [d: input][append data d] probe sort data
(Note: This is not a tutorial on file redirection, so see your OS docs for more info on how it is done.)
But, the question comes up: how should REBOL behave? And the answer really comes down to two choices:
While the first choice may be useful for generating documentation and performing tests, the second choice is more useful for connecting REBOL with other Unix commands as well as for working within an editor environment that sends the current edit buffer to REBOL's standard input for execution (and displays the results in the editor window.)
For the general case, I think the second choice is the more useful and also the more common case for existing applications. Unless you have a very good reason why not to do that, I think this choice will become part of future versions of REBOL (very soon in fact.)
If you want to contact me on this matter to try to change my mind, please do so on the Carl's Blog group in the REBOL AltME world.
Post a Comment:
You can post a comment here. Keep it on-topic.