Output Issues

[rgchris]

I'm trying to redirect output by switching out the OUTPUT port (as I might with Rebol 2). I have my capture function as follows:

capture-output: func [
    body [block!]

    /local output-port capture-port target content result
][
    output-port: system/ports/output
    capture-port: open/write/new target: %/tmp/capture.tmp.bin
    system/ports/output: capture-port

    ; catch an error because we'll need to close the file port
    ;
    error? set/any 'result try [
        apply func [] body []
    ]

    system/ports/output: output-port
    close capture-port

    content: read/string target
    delete target

    either error? :result [
        do :result
    ][
        content
    ]
]

It seems PRINT bypasses the OUTPUT port:

>> out: capture-output [print "Foo"]
Foo
== ""

I'm sure there's probably other ways to do this (ECHO comes close, but duplicates output). Ultimately I'd prefer to have a scheme that accumulates output to a STRING! and stick that in the output slot, but that's for another day.

Edit

I do not want to imply that an output or capture port should only support strings, they should be able to handle binary too.

[rgchris]

Not entirely unrelated, it doesn't seem as if the Console scheme (default SYSTEM/PORTS/OUTPUT) supports binary writes to STDOUT. Is there a scheme that permits this?

[Oldes]

Not at this moment... write on the console scheme was not supported at all in the original R3 version...
Now it works just like prin.

Btw.. you are not the only one who requests better console scheme... feel free to submit a wish with some proposals, how it could work. I can give it some time, when I will be done with the new Unicode support.

[rgchris]

In Rebol 2, the STDOUT interface varied depending upon how Rebol was invoked. If you opened Rebol in the terminal, you got the Console scheme. If you ran it as a shell script or with a script argument, you got the File scheme. This level of abstraction was useful as neither scheme really makes sense when used the other way around: the console scheme leaks meaningless output (>> or ==) when shell scripting, and outputting arbitrary binary makes little sense in a REPL.

One way to consider this is through the lens of CALL. If you CALL/INPUT/OUTPUT a Rebol sub-instance with Binary buffers, it would seem reasonable that you might fill those buffers with arbitrary binary content—for example, image or compressed content. This flexibility allows Rebol to sit as a conduit at any point in a shell scripting chain. A practical example of this is a CGI response containing compressed content, image content, or some other non-textual data such as Msgpack content.

The Console scheme is an essential user interface when a REPL is desired, I don't really have an opinion on the current scheme in that regard—it seems fine enough. However, it's an impediment when used in scripting environment where, even if it's not the File scheme as used in Rebol 2, a separate scheme that is pure binary IO is desirable.

[Oldes]

I would appreciate a more detailed proposal on how it should be done. Preferably with some code examples, as I struggle a lot with naming things.

[rgchris]

My model is pretty much Rebol 2 (which was not always perfect in this regard). Some way of facilitating the following:

call/output "rebol bin.reb" out: #{}
out == #{0badCafe}

Where bin.reb contains:

Rebol [...]
write system/ports/output #{0badCafe}

I have more thoughts on this, will follow up.

[rgchris]

Observations from Rebol 2

As I understand it, Rebol 2 used some mechanism to detect whether it was invoked in a Terminal or not; in doing so it then determines which output interface it presents.

If Rebol 2 is invoked from the terminal, it uses the CONSOLE scheme.

$ rebol -qs --do "probe system/ports/output/scheme"
console
>> [rebol prompt]

$ echo "probe system/ports/output/scheme" | rebol -qs
>> console
$ [shell prompt]

$ echo "probe system/ports/output/scheme" | rebol -qs --do "do input"
console
$ [shell prompt]

$ rebol -qs ~/.rebol/test-io.r2
console
$ [shell prompt]

If Rebol 2 is invoked by other means, it uses the FILE scheme:

>> also out: "" call/wait/input/output {rebol -qs --do "probe system/ports/output/scheme"} "" out
== "file^/>> "

>> also out: "" call/wait/input/output {rebol -qs} "probe system/ports/output/scheme" out
== ">> file^/== file^/>> "

>> also out: "" call/wait/input/output {rebol -qs --do "do input"} "probe system/ports/output/scheme" out
== "file^/>> "

>> also out: "" call/wait/input/output "rebol -qs ~/.rebol/test-io.r2" "" out
== "file^/"

Notes: all tests on MacOS Terminal; in the above examples, test-io.r2 contains: Rebol [] probe system/ports/output/scheme; the presence of >> in some of the results indicates that the Console abstraction is leaky.

This gets to the essence the different ways that Rebol is used and the different interfaces. If run from the Terminal, you get some REPL features managed by the Console scheme; if run from another process, you get basic I/O (I can't say that the File scheme offers the best abstraction, perhaps it does). The basic I/O would presumably allow for arbitrary binary input and output.

Unfortunately, as Rebol 2 is closed source, it's tricky to say how it makes these various choices, or how it uses the File scheme as an interface to I/O in 'shell' mode; it does demonstrate that it's possible though. It is a bit messy as-is, it would seem that there's an opportunity to make a much cleaner interface altogether.

As I mostly care about the CALL methods, I'd like to see the following work a little cleaner:

>> also out: "" call/shell/wait/input/output {rebol --do "probe system/ports/output/scheme"} "" out
== "file^/"

>> also out: "" call/shell/wait/input/output "rebol" "probe system/ports/output/scheme" out
== "file^/"

>> also out: "" call/shell/wait/input/output {rebol --do "do input"} "probe system/ports/output/scheme" out
== "file^/"

>> also out: "" call/shell/wait/input/output "rebol ~/.rebol/test-io.r2" "" out
== "file^/"

Notes: no QUIET required and perhaps some way to bypass the SECURE, maybe through shell variables(?)

The second case, call/wait/input/output "rebol" "...code..." out is a mechanism used by other languages, e.g. Ruby.

And obviously:

>> also out: #{} call/shell/wait/input/output "rebol" "write system/ports/output #{0badCafe}" out
== #{0BADCAFE}