Recent

Author Topic: capture apl_exec stdout  (Read 7126 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #30 on: January 17, 2023, 10:21:34 am »
It is possible the C++ code does that.
The U part error is non-standard user error re-direction and needs a call back afaict. But it is no problem to use a file for that. It is used to report syntax errors etc.
CIN,COUT and CERR have no problems, nor on windows nor on linux, simple standard OS handles. libapl simply inherits the handles of the pascal process.
Much easier than I thought.
(My test environment is windows 10 windows 11 and debian bullseye, all 64 bit)
« Last Edit: January 17, 2023, 10:29:05 am by Thaddy »
Specialize a type, not a var.

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #31 on: January 17, 2023, 10:24:15 am »
It *should* work.
See example named redir2b.pas

Quote
Will investigate. I will add the redirect options to the unit when written and tested.
appreciated. :thumbsup:

BTW: I've updated post #17 again with your additions. Thank you Thaddy !
« Last Edit: January 17, 2023, 10:32:42 am by TRon »

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #32 on: January 17, 2023, 10:25:18 am »
The U part error is non-standard user error re-direction and needs a call back afaict. But it is no problem to use a file for that. It is used to report syntax errors etc.
CIN,COUT and CERR have no problems, nor on windows nor on linux, simple standard OS handles. libapl simply inherits the handles of the pascal process.
Much easier than I thought.
Unfortunately UERR is also used for command output  :'(

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #33 on: January 17, 2023, 10:30:11 am »
Then we need to duplicate the handles....?
Specialize a type, not a var.

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #34 on: January 17, 2023, 10:30:22 am »
I reacted to the Toby post immediately above it. Should have quoted.
Sorry i should have been more explicit.

I assumed that you "got trigerred" by

using apl_command(')help'); is redirected
but apl_exec('2 < 1 1 1');   doesn't
And I understand why (hence my reaction) :)

Quote
Another tidbit that surfaced while reading through this thread: While I do work on TProcess from time to time, I am not that versed in *nix side of things anymore. But iirc some kinds of redirection there worked on glibc ( or c++ stdlib?)  level rather than on handle level. It is possible the C++ code does that.
Thank you for that insight. For sure there is something odd there as redirecting stderr to a file (as suggested by Fred vS) has the wanted effect alas it seems that can't be replicated by using other means (at least not to my current knowledge). I could perhaps try using pipes or reroute using another (new created) handle.

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #35 on: January 17, 2023, 10:47:17 am »
Then we need to duplicate the handles....?
Sorry, I have to correct myself There. It is not the command output rather the output (apl_exec() result ) from the interpreter that seem to get emitted to UERR.

TBH I have no idea how to approach this atm.

My intial thought is/was to compile libapl with the android option and provide/export the missing variables in FPC. But then I would have no idea how C expects CIN/COUT/CERR and UERR to be initialized and/or how they are stored in memory. My knowledge on c++ internals is rather empty.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #36 on: January 17, 2023, 11:10:20 am »
No, you do not have to correct yourself, it is correct,  what you stated is to the point. Working on it.
CIN/COUT/CERR is done and was easy. Trying to find a creative solution for UERR, that is not standard for C++ iostreams.
Basic Idea is to clone the handle from stdout to UERR. Possibly the other way around  ;D
May be as easy as moving the apl_init call up in the call chain.
Will report back on progress.
« Last Edit: January 17, 2023, 11:19:02 am by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #37 on: January 17, 2023, 11:30:15 am »
One important thing to note too, is that when you write a GUI app, for the redirection to work the GUI application needs to be compiled with {$apptype console} NOT {$apptype GUI} where you hide the console in code. This is because {$apptype GUI} does not generate handles for stdin/out/err. (or you need to create the console manually). You will still have a GUI application.

Code will follow, now busy solving UERR.
« Last Edit: January 17, 2023, 11:31:54 am by Thaddy »
Specialize a type, not a var.

toby

  • Sr. Member
  • ****
  • Posts: 251
Re: capture apl_exec stdout
« Reply #38 on: January 19, 2023, 12:24:42 am »
Fred VS

what about assigning what is written to the file to an ansistring instead or better adding it to a tstringlist.add(...)?

it is possble?


Fred vS

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: capture apl_exec stdout
« Reply #39 on: January 19, 2023, 12:43:32 am »
Fred VS

what about assigning what is written to the file to an ansistring instead or better adding it to a tstringlist.add(...)?

it is possble?

fpdup2 needs an OS handle, like Thaddy explained here:
https://forum.lazarus.freepascal.org/index.php/topic,61841.msg467050.html#msg467050

So instead of a file (if you dont like it) you can try with a THandleStream (you may ask to Thaddy how to do it  ;) )
« Last Edit: January 19, 2023, 01:03:13 am by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: capture apl_exec stdout
« Reply #40 on: January 19, 2023, 10:14:43 am »

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #41 on: January 19, 2023, 02:10:24 pm »
Making progress:

Set WriteErrorsToStdErr to False. This is a FPC system variable which defaults to true.
If it is false everything goes to stdout/Output.
UERR is simply a set of C++11 formatting macro's and relates only stdout and stderr, so we do not need to handle it in any special way.

https://freepascal.org/docs-html/rtl/system/writeerrorstostderr.html

Quite a bit off the beaten track, here... Hmm, should have known that, but I did't... Not even its existance.
« Last Edit: January 19, 2023, 02:30:32 pm by Thaddy »
Specialize a type, not a var.

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #42 on: January 19, 2023, 02:17:02 pm »
@toby:
afaik there is something wrong with the (default) make/configuration options.

When building the library as you described it generated the libapl.so file.

However, when you try to load that library dynamically you get a: "Error loading library /path/to/library/libapl.so: undefined symbol: main" indicating that this is not a standalone library rather expects the library to be (statically) linked against.

Adding --enabled-shared to the configuration does not help.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: capture apl_exec stdout
« Reply #43 on: January 19, 2023, 02:26:11 pm »
@TRon

I prefer to link it statically for the time being. Does that work for you?
If not we three need to synchronize our libraries so we are barking all up to the same tree.. :) O:-)

btw UERR seems fixed here.
Specialize a type, not a var.

TRon

  • Hero Member
  • *****
  • Posts: 2432
Re: capture apl_exec stdout
« Reply #44 on: January 19, 2023, 03:17:34 pm »
I prefer to link it statically for the time being. Does that work for you?
Yes .. and no  :D

I've extended the header unit with dynamic loading and wanted to test.

Which brings me to the second point. I have not installed APL as intended, therefor required to set the library path in order to link (my prerogative as I wanted to start testing with Lazarus).

Quote
If not we three need to synchronize our libraries so we are barking all up to the same tree.. :) O:-)
No problem for testing purpose I can stick to linking.

Quote
btw UERR seems fixed here.
Then you are a greater man then I am, because it does not seem to matter what I do as I am simply unable to shut off the chatter of libapl. For some reason FPC does not seem to pick up the chatter on StdErrorHandle for me (even though I explicitly tell it to: example redir2b is wrong in that regards).

 

TinyPortal © 2005-2018