REBOL Technologies

Input and Output Redirection in REBOL

Carl Sassenrath, CTO
REBOL Technologies

Article #0004
Main page || Index || Prior Article [0003] || Next Article [0005] || Post Comments || Send feedback

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:

  1. Act exactly like interactive mode, but use the input file for all command line inputs. In other words, output a prompt, get input data, echo input data, evaluated the input, output a result indicator (==), then the results.
  2. Act in a special "non-interactive" way that is more useful for "piping" actions. In this case, do not output a prompt, do not echo input data, do not output a result indicator, and do not print the results. That means only explicit output (e.g. PRINT commands) are sent to the output file.

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 Comments

Updated 10-Mar-2024   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code