Hyperion Entertainment Message Boards

I did observe that U-boot has a stdout env variable which is not of course the one that vould be used,
but setting the OS4. stdout through such an environmental variable would do the job

That's not going to help you. The U-Boot "stdin" and "stdout" are only for the U-Boot CLI streams, and hence only work while U-Boot is running. They don't affect anything in OS4.

@tinyw

The U-Boot "stdin" and "stdout" are only for the U-Boot CLI streams, and hence only work while U-Boot is running. They don't affect anything in OS4.

I appreciated that, as stdout to vga definitely is not what stdout in OS4 is about.
I just suggested that providing (setting, changing ) an OS4 stdout environmental variable, would neatly do what i am askong for:
changing the stdout during execution of a script (DOS, arexx Gui4Cli, python)
A dedicated CLI commond permitting to do the same from a script would do too of course (this was what CMD permitted)

JosDuchIt wrote:Set OUTPUT con:360/12/160/80/Gui4Cli/auto/close/wait §Gui4Cli command
CLI 'run cmd parallel PRT: opt n '
CLI ' run cmd parallel RAM:PrtFile opt n' ;
any alternative to that ?

Sorry but I don't understand what you are trying to accomplish here.

Are you trying to print a file from CLI or something?

@ssolie

Are you trying to print a file from CLI or something?

No not at all

I was able to manipulate Gui4Cl'is debug output or the output of any application to stdout, reidrecting it to a file (or the printer - i donthave one working )
using CMD . I think you could also redirect it to the serial output)

Being able to redirect the output when launching an application is far more limited: you can't change that afterwards.

If i recall well the Gui4Cli interface to Ghostscript i wrote, used CMD in this way.
You do send a string to Ghostscript (using stringins on OS4, scripit under OS3) Ghostscript produces some output, you direct it to a file and then use that info as appropriate.
There were other interfaces using CMD this way.
The same approach is indeed valid for any (linux) CLI only program.

I want to be able to catch and direct to different files (or print them out) output that only pertain to some (different) "application time sequence".

To give an example: Ctl_V will for an active GUI4CLI script produce in Gui4Cli's debug output the list of all the current variables and their values.
I want to catch this output easily before execution of a (Gui4Cli) "command sequence" and after, then compare those outputs.
I am able using "stringins" to simulate such a Ctl V triggered before and after a chosen command sequence.
(using the Gui4Cli xBEFORE & xAFTER event)
If i can direct the Ctl_V xBEFORE output to 1 file, the Ctl_V xAFTER variables info to an other file and the normal debug output to a third one or just to the normal debug output,
that would be neat. I could autmatically compare the variables before and after & present a clearer, smaller comparison
"var x" "value before" "value after"
At the moment i have them all in sequence: a long list of variables info, the debug output, again a long list of variables info in the debug output.

When you run a program from CLI, DOS assigns stdin and stdout for you. They are normally assigned to the console input (stdin) and console output (stdout). Stderr is also assigned to stdout by default.

You can change those streams to other sources/destinations by specifying a path on the command line (as you already know). But, once set, they can not be changed. Your only recourse is to open another stream to the new destination. Opening a new stream/file is fairly trivial (see DOS docs), but you must remember to close it nicely when you exit.

Since stdin, stdout and stderr are private to the application, a global definition is not possible. I think you want the "Reassign" command of DEC's RSX-11 (or was it "Redirect"?), whereby you could reassign output or input from one device or file to another at any time. I can't think of a way to do it in AmigaOS, though.

@tonyw

I think you want the "Reassign" command of DEC's RSX-11 (or was it "Redirect"?), whereby you could reassign output or input from one device or file to another at any time.

Exactly!
Why would it be a problem to redirect straight stdout output to an other device on the fly? How could this hurt the application?

I can't think of a way to do it in AmigaOS, though.

How did CMD do it ? I think it is a very old program (earlier than OS3.1) so sources should be available (to Hyperion)
Probably the way you described:

Your only recourse is to open another stream to the new destination. Opening a new stream/file is fairly trivial (see DOS docs), but you must remember to close it nicely when you exit.

You are right of course when you say having a global environmental variable defining stdout (or stderr, stdin) is out of the question

Opening a new stream/file is fairly trivial (see DOS docs), but you must remember to close it nicely when you exit.

Having looked back at my ghostscript Gui, i noted that contrary to what i wote in this thread i did not ise CMD there:
When launching an application (here ghostscrip) with the Gui4CLI command "CLI" its output is directed to Gui4CLI's stdout
So it is only this last one that i need to manipulate.
As said before programming this into Gui4Cli, while maybe not to difficult, does not motivate me enough to take on another C-programming effort now.

It is clear that using "run CMD" allowed you to redirect stdout to PRT: and then to the file using opt n.
I don't know however where that opt n came from as it is not mentioned in the OS3.9 manual

I did find a solution to my immediate problem :
as i can set & reset from within a GUI4Cli script the output console with
set OUTPUT con:...
i dropped the idea of redirecting the output to a file(directly) and replaced it with manipulation of the console
addressing the console with WTF & with stringins, its possibility to copy all to clipboard.
(A_M & A_C keys)

Using the xBEFORE event that triggers before any (gadget related) command sequence is executed
is then sufficient for what i want.
The endresult will be:
the normal debug information for any (gadget triggered)command sequence is numbered & saved to t:
The additional (Crl_V) variable info will also be saved for each command sequence
Only the debug info related to the last command sequence and corresponding variable situation Before & after (generated with the UNDO button)
will be visible directly in the last opened consoles.
In a still more sophisticated version the variable sitution will be merged and simplified in a Gui4CLI window
Less simple than with CMD (or a CLI command replacing it) for which i maintain a feature request.
May i stress that this would be helpfull for any scripting language (python, arexx)
Now maybe somebody can write this using arexx ???

A "Save As" (with shortkey) would shorten the script outlay, an arexx port for the console still more.
(No stringins nor wtf needed)

JosDuchIt wrote:Being able to redirect the output when launching an application is far more limited: you can't change that afterwards.

What about using the shell's internal Recorder command?

@ssolie

What about using the shell's internal Recorder command?

sounded great
works well with DOS or arexx scripts, a really nice possibiliy
There are problems using Recorder in a Gui4CLI script
- you probably can only use Recorder when gui4cli is launched from the shell (maybe that's not true though, i am testing it now launching Gui4Cli that way)
Gui4CLI has 3 ways of launching a DOS program
CLI " DOS commandline "
RUN " DOS CommandLine"
Launch "DOS commandline" (detaches as RUN but you can set up an event that triggers when the program returns)
I tested only with CLI & RUN


From a shell's commandline
Recorder ram:output &
Run Recorder ram:output
both work well & in both circumstances you can close the recordingstream just using
Recorder off


Under Gui4Cli even CLI "recorder" gives an error message
85: CLI recorder
=> recorder
RECORDER: object is not of required type (same if i specify a filepath)
recorder failed returncode 10
Aborted: RetCode = 10

If i use RUN (in a gui4cli script)
RUN "recorder ram:test"
i get no error message, the file is created but it remains empty & trying to close it
CLI " recorder off "
or
run "recorder off"
get an error message
"RECORDER: Recorder is not running"


i finally tested

126: CLI run recorder ram:rec__1
=> run recorder ram:rec__1
RECORDER: object is not of required type
[CLI 14]
recorder failed returncode 10

If you can get the commands to work in a Shell but not in a Gui4CLI script, then I suggest that you add some debugging output to Gui4CLI and find out what it is doing wrongly.

Perhaps it would be useful to print out the actual command that it issues.