Assuming that test1 is the app (executable file), what are argument1 and argument2? I was hoping for a real world example, with actual, presumably, file names and the output.
Argument1 and 2 are simply the strings I entered in the DOS window. If I'd entered test1 fred bert yo'd have seen fred as parm1 and bert as parm2.
The same logic applies to the ED plug-in. Since I specify $INPUTFILEPATH as the argument, then ED obviously passes the name of each file to be compared to my exe plug-in.
You also suggest that the BC plugin is used like: H:\A_MS_exe\BC_CONVERT_MFE_FILE.exe %n %s %t
where %n %s and %t are defined as %s source file %t target file %n original file
- so does that mean the BC plugin gets handed both of the files that are being compared? If not, what did source/target/original mean?
Now that you put the question, I'm GUESSING (without testing) that the %n parm isn't needed. Somewhere or other, I got the code working and then left it at that.
As to the ED printout, all it shows is that my plug-in is only called with ONE parm, the input file.
Note how the first parm to LINEOUT is missing. This is what the Rexx documentation says
result = LINEOUT(stream, string, position)
Args
stream is the name of the stream. It can include the full path to the stream (ie, any drive and directory names). If omitted, the default is to write to STDOUT (typically, display the data in the console window).
Could it be that I need to (DOS-wise) direct my console output to STDOUT. At the moment, the output is written to a console window (the black one attached earlier) that is opened on the fly. Maybe that's my problem ?
Your rexx exec IS writing to sysout - that's what both 'say' and lineout used that way do. The console window IS sysout.
Is the test1 rexx exec compiled? If it isn't then the .exe you need to define in the plugin definition is probably your regina / oorexx interpreter, passing it a parm of the rexx source file's name, and then the name of the ABEND.DAT file you are trying to convert.
If the test1 exec is compiled then the plugin definition presumably only needs the path to the compiled exec followed by the $INPUTFILEPATH symbol.
I just tried this here with ooREXX v4.2.0 (and an interpreted rexx exec rather than a compiled one) and it did what I expected.
I used a simple 'showargs.rex' which contained:
/* REXX */
parse arg alla
parse source alls
say "Rexx: args:" alla
say "Rexx: source:" alls
exit 0
My rexx interpreter lives in: "C:\Dropbox\Programs-NP350\~open-source ooRexx V4-2-0\rexx.exe"
The showargs exec is in: "C:\Dropbox\JN_RexxExecs\Showargs.rex"
I defined the plugin as follows
plugin JNtest
filter *.*
app "C:\Dropbox\Programs-NP350\~open-source ooRexx V4-2-0\rexx.exe"
args "C:\Dropbox\JN_RexxExecs\Showargs.rex" $INPUTFILEPATH
use exit code? yes successful exit code: 0
I then compared two simple text (.txtplain) files. In the lefthand window what I then saw was:
Rexx: args: "C:\Users\myuser\AppData\Local\Temp\~~~JN - dir 'WPDNSE' is something to do with WMP 11.txtplain"
Rexx: source: WindowsNT COMMAND C:\Dropbox\JN_RexxExecs\ShowArgs.rex
and in the righthand window I saw:
Rexx: args: "C:\Users\myuser\AppData\Local\Temp\~~~JN - 'etilqs' files are created by SQLite, eg via Dropbox,FF.txtplain"
Rexx: source: WindowsNT COMMAND C:\Dropbox\JN_RexxExecs\ShowArgs.rex
So, you can see that
a) EDP has sucessfully called the rexx interpreter twice, passing it the name of the rexx exec and the file I'm comparing,
then without being told to, read the sysout from that rexx exec's execution
b) the plugin was called for each file
c) the first (and in this case only) argument passed to the rexx exec was the full filepath of a file in my temporary files folder
d) the plugin has also shown its own name (from parse source)
> I assume I can't define the argument along the lines of $INPUTFILEPATH >1 (or however you write it)
You don't need to. EDP (according to the help pages on plugins) assumes that a plugin, if you don't tell EDP otherwise, will write to sysout. Perhaps if you looked at the definitions of the supplied plugins you'd see that that is how others are defined?
> Do you know of some way to redirect the say/STDOUT so it really goes to the "proper" STDOUT ?
It already does, according to (a) what I'd expect (writing rexx for 30 years), and (b) what your command window screenshot shows.
Hang on... I know what the problem is. Your compiled exec isn't running in the command window you call it from, but is opening a new instance of cmd.exe to run the exec.
I don't know which version of rexx you're using, but in ooREXX terms this is like the difference between using rexx.exe and rexxh.exe (to run interpreted execs). Maybe when you compile the exec (which I've never done) there's a choice about how this is to be handled, or a choice between a 'console' exec and a 'hidden' one? You need the console option.
When I run it using H:\A_MS_rexxcode\test1.rex as one file and a simple txt file as the other, I get the screen capture shown.
If I remove the Use exit code, I get no error message (nor surprising), but I don't see ANY data in the ED panes
Attachments
2017-09-13_22-28-53.jpg (41.52 KiB) Viewed 20324 times
Maybe 'compiled' rexx execs are not meant to produce any sysout - maybe the assumption is that they run 'silently'? Ie either only handle files, or use (in ooREXX terms) ooDialog or the simple prompt and message functions to commmunicate with a user.
When you ran your plugin at your last employer, did you have the impression that a cmd window ever opened and closed immediately? That would show itself as just a flicker as the window(s) came and went? If that did happen then there's no probably no way to prevent another window opening, but it would maybe explain why your BC plugin required an explicit output dataset, so it didn't write to sysout in the secondary cmd window (if there was one).
To psguru - there aren't many rexx compilers around. Even what some people call 'compiled' rexx execs are not compiled in the usual sense of the word, but are just a way of obscuring the source code. The 'compiled' exec contains tokenised original source, and is still interpreted when it finally runs. In ooREXX (at least) one can write a small C (for example) front end to load the tokenised code into memory and start running it. Maybe that's what the OP's .exe does. I don't know how it works under the covers.
GOING BACK TO THE ORIGINAL plugin, which appeared to need three parameters, which appeared to be the input file twice followed by an output file.
Have you tried defining it with args: $INPUTFILEPATH $INPUTFILEPATH $OUTPUTFILE
Maybe that would run it forcing its ouput into the EDP-defined output file?
> I tried your variation (I'm using Reginald Rexx, but they should be roughly the same).
Reginald's not something I've seen any reference to for years and years. I think it used to crop up in discussions in comp.lang.rexx quite a lot. The problem with it was that Jeff Glatt took an early version of Regina and extended it in all sorts of unusual ways, making it great to program with, but completely out of step with other versions of REXX.
You say you defined this test with:
Application C:\Program Files (x86)\Reginald\RxLaunch.exe
Arguments H:\A_MS_rexxcode\test1.rex $INPUTFILEPATH (an uncompiled Rexx script)
Use exit code (yes) and success code zero.
and maybe your text exec this time was
/* REXX */
arg parms
return 0
I say "maybe" because your plugin arguments say you're still calling "test1.rex" but you described that source as "test.rex" which is not the same filename. Assuming that's just a typo, those lines of rexx don't generate any output - there's no SAYs. So you wouldn't get anything even if the
calling logic worked.
You also show an error message box which says the exit code was 1. That says to me that the exec probably wasn't found, or wasn't run.
I don't know if it is needed, but as a matter of good practice I'd always enclose filenames in double quotes. So for example instead of
When you ran your plugin at your last employer, did you have the impression that a cmd window ever opened and closed immediately? No. The plug-in was ran, read the input file, created the output file and BC then (under the covers ?) read the output file into memory.
but it would maybe explain why your BC plugin required an explicit output dataset, so it didn't write to sysout in the secondary cmd window That makes sense to me
GOING BACK TO THE ORIGINAL plugin, which appeared to need three parameters, which appeared to be the input file twice followed by an output file.
Have you tried defining it with args: $INPUTFILEPATH $INPUTFILEPATH $OUTPUTFILE Tried that, didn't help. I got a message about $OUTPUTFILE not containing anything.
In general, the way to debug a plug-in is to forget EDP for a minute and make sure that you can open a CMD window and run a console program successfully, either by creating an output file or by outputting the result into the command window itself (STDOUT). Once you achieve that, setting up EDP will be easy.
> In general, the way to debug a plug-in is to forget EDP for a minute and make sure that you can open a CMD window and run a console program
> successfully, either by creating an output file or by outputting the result into the command window itself (STDOUT). Once you achieve that, setting
> up EDP will be easy.
Absolutely... but the earlier example where the OP ran a much simpler routine in a command window, and it didn't create output in that window but instead opened another one, presents a problem I think, if the actual plugin also has a similar internal call structure. It's also not helpful that the OP doesn't seem to know what the three parameters of the original BC plugin are for.
