O.K. came up with a version intended to be usable for "input using" as well:
"NullDevice.rex"
.environment~nullDevice=.nullDevice~new
::class "NullDevice" subclass InputOutputStream
-- InputStream
::method charIn unguarded -- implement abstract method
raise notReady
::method chars unguarded -- implement abstract method
raise notReady
::method lineIn unguarded -- implement abstract method
raise notReady
::method lines unguarded -- implement abstract method
raise notReady
-- OutputStream
::method say unguarded
::method lineOut unguarded -- implement abstract method
::method charOut unguarded -- implement abstract method
However, there is a problem when redirecting stdin: although LINEIN gets triggered it does not cause
the client program to end, it rather hangs (waits for additional input it seems)!
Here the test programs (one using 'parse pull' and one 'parse linein' with intercepting the notready
condition):
Using "parse pull line":
echo2stdout.rex
do forever
parse pull line
if line="" then leave
say line
end
runTest.rex
cmd="rexx echo2stdout.rex"
address system cmd with input using (.nullDevice)
::requires "NullDevice.rex"
a) invoking the program (this hangs on Windows and Unix):
rexx runTest.rex
b) invoking the program in this way works (in addition redirecting from an
existing file) on
Windows, but not on Unix (Apple, Linux):
rexx runTest.rex < someFile.txt
Using "parse linein line" with NOTREADY:
echoLineIn2stdout.rex
signal on notready
do forever
parse linein line
say line
end
notready:
runTestLineIn.rex
cmd="rexx echoLineIn2stdout.rex"
address system cmd with input using (.nullDevice)
::requires "NullDevice.rex"
a) invoking the program (this hangs on Windows and Unix):
rexx runTestLineIn.rex
b) invoking the program in this way works (in addition redirecting from an
existing file) on
Windows, but not on Unix (Apple, Linux):
rexx runTestLineIn.rex < someFile.txt
When using output redirection with ADDRESS...WITH there is no need to redirect the output on the
command line in addition.
---rony
On 04.12.2022 19:05, Rony G. Flatscher wrote:
The class needs to subclass OutputStream as otherwise ADDRESS ... WITH would not accept it as a
target.
Here the tested implementation:
::class "NullOutput" subclass OutputStream
::method say unguarded
::method lineOut unguarded -- implement abstract method
::method charOut unguarded -- implement abstract method
To add to environment:
.environment~dev.null=.NullOuput~new
To use it (for testing purposes using it for output and error, i.e.
concurrently):
ADDRESS SYSTEM 'someCommand' WITH OUTPUT USING (.dev.null) ERROR USING
(.dev.null)
---rony
On 04.12.2022 17:42, Rony G. Flatscher wrote:
Thank you all for your feedback and suggestions which is highly appreciated.
The reason for asking has to do with the semantics that "nul" resp. "/dev/null" convey when
redirecting to them.
Actually students who learn about the nice redirection feature of ooRexx ask for it (here the
slides of that unit:
<https://wi.wu.ac.at/rgf/wu/lehre/autowin/material/foils/060_ooRexx_commands_V16.pdf>, the last
slide also demonstrates how to use (.array~new) short of a null device). As the aim is to make it
as easy for them (and transferring concepts from/to ooRexx easily) the question/idea.
Will add an entry to .environment named "dev.null" which will be an instance of a class like
yours in BSF.CLS (adding unguarded to the methods so to allow using the object's methods
concurrently).
This will allow ooRexx lurkers to convey the semantics and make ooRexx code a little bit more
like pseudo-code that can be easily understood even if one is not an ooRexx programmer:
address system 'some command' with output using (.dev.null)
or
address system 'some command' with error using (.dev.null)
Maybe having such an environment symbol solely for supporting redirection to the null device in
ooRexx might be justified?
---rony
On 03.12.2022 20:16, Rick McGuire wrote:
-1. This would require a change to the .Monitor class beyond it's original intent. However, this
is easily accomplished already with a simple custom class:
::class nullOutput
::method say
::method linout
Use that as the target and the output will be discarded.
Rick
On Sat, Dec 3, 2022 at 1:22 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
Redirecting stdout and stderr on the commandline allows one to redirect to
the null device
(on Windows "nul", on Unix "/dev/null"), e.g.
someCommand >nul (Windows)
someCommand >/dev/null (Unix)
someCommand 2>nul (Windows)
someCommand 2>/dev/null (Unix)
There are redirections where the same need occurs with redirected command
handlers.
Therefore it would be helpful, if .nil could be used as the null device on
ooRexx redirected
commands such that ooRexx would ignore any output to that destination.
Something like
address system 'some command' with error using (.nil)
or
address system 'some command' with output using (.nil)
instead of
errArr=.array~new
address system 'some command' with error using (errArr)
where "errArr" never would get used in the Rexx program.
or
outArr=.array~new
address system 'some command' with output using (outArr)
where "outArr" never would get used in the Rexx program.
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
