On 14/12/2023 20:54, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 20:29 schreef Martin Frb via fpc-devel:
Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided).
It does, if you need a runcommandloop like routine that writes to
file. Partially this can be even simplified by inheriting TProcess
and overriding readinputstream
But that means the parent process has to read the data (from the
file) and forward it.
Without a shell that always needs to happen. How else ? Keep in mind
that TProcess is a kernel and not a shell level concept.
At least on Windows you can give a handle that is to be used as StdIn.
And on Linux that handle is currently setup after the fork event, in the
new process => and currently it either is a pipe or (I think) a copy of
the parent stdin. But nothing stops it to be a filehandle.
But afaik StdIn is just a handle. This handle can be a tty (usually if
there is a shell), but it can be /dev/nil or a file or ...
I am actually pretty sure, on Linux, I can get what I want by doing it
in the "OnFork" event of TProcess.
But on Windows it is well hidden away in the "Execute" method, nothing
virtual that could be intercepted.
Also not sure how to simulate an EOF in that case....
Probably close the pipe.
Anyway the full project is here:
http://www.stack.nl/~marcov/files/processmemodemo.zip
It is slightly different, a TProcess based application that tries to
instrument a secondary binary.
Thanks, but I consider that a worst case work around.
I'd rather copy the entire TProcess, so I can make a few tiny changes in
TProcess.Execute.
I already done a proof of concept on win:
- get the handle to the file
- pass it to the WinAPI for creating the process
=> works.
Haven't yet looked at Linux. But should be even easier.
-----
The reason I ask is, that if there is a chance of a future solution in
FPC, then I like to avoid my own solution now until I can at least do my
own solution in a compatible manner.
For that I would have to know enough details on that future solution.
Well depending on the amount of changes, I may still do my own
incompatible....
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
