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.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
CMD printer output redirection
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: CMD printer output redirection
cheers
tony
tony
Re: CMD printer output redirection
@tinyw
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)
I appreciated that, as stdout to vga definitely is not what stdout in OS4 is about.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 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)
Re: CMD printer output redirection
Sorry but I don't understand what you are trying to accomplish here.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 ?
Are you trying to print a file from CLI or something?
ExecSG Team Lead
Re: CMD printer output redirection
@ssolie
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.
No not at allAre you trying to print a file from CLI or something?
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.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: CMD printer output redirection
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.
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.
cheers
tony
tony
Re: CMD printer output redirection
@tonyw
Why would it be a problem to redirect straight stdout output to an other device on the fly? How could this hurt the application?
Probably the way you described:
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
Exactly!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.
Why would it be a problem to redirect straight stdout output to an other device on the fly? How could this hurt the application?
How did CMD do it ? I think it is a very old program (earlier than OS3.1) so sources should be available (to Hyperion)I can't think of a way to do it in AmigaOS, though.
Probably the way you described:
You are right of course when you say having a global environmental variable defining stdout (or stderr, stdin) is out of the questionYour 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.
Having looked back at my ghostscript Gui, i noted that contrary to what i wote in this thread i did not ise CMD there:Opening a new stream/file is fairly trivial (see DOS docs), but you must remember to close it nicely when you exit.
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
Re: CMD printer output redirection
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)
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
Code: Select all
xBEFORE ; have only a before & generate an after with the "undo"
;///CLI ' run cmd parallel env:.Wget_Vars2 opt n'
G4O_NrL = $G4O_Nr : 0 to start with (the default routine on opening the script's GUI )
++G4O_Nr ; 1st mode only maintain the 2 last windows visible, save the rest ,
Set OUTPUT con:360/12/160/80/BEFORE_$G4O_Nr\#/auto/close/wait
CLI 'Stringins delay=1 "\\cv"' ; // the Ctrl_V variable information is sent to the numbered console
;// address the Gui4Cli_$G4O_NrL - console with WTF // the default sequence generated debug info too
;// address with stringins A_M (mark all)
;// address with stringins A_C (copy to clipboard)
Gosub #this SaveClips t:.DBug_G4C$G4L_Nr LVUse #this 101
;// address with stringins A_K (close shell or A_Q close all)
IF $G4O_NrL > 1 ;// there have been at least 2 BEFORES
// address the BEFORE_$G4O_NrL - consoles with WTF
;// address with stringins A_M (mark all)
;// address with stringins A_C (copy to clipboard)
Gosub #this SaveClips t:.DBug_G4C$G4L_Nr LVUse #this 101
;// address with stringins A_K (close shell or A_Q close all)
Set OUTPUT con:360/12/160/80/Gui4Cli_$G4O_Nr\#/auto/close/wait
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)
Re: CMD printer output redirection
What about using the shell's internal Recorder command?JosDuchIt wrote:Being able to redirect the output when launching an application is far more limited: you can't change that afterwards.
ExecSG Team Lead
Re: CMD printer output redirection
@ssolie
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
sounded greatWhat about using the shell's internal Recorder command?
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
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: CMD printer output redirection
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.
Perhaps it would be useful to print out the actual command that it issues.
cheers
tony
tony