On 20/07/2026 19:56, Adriaan van Os via fpc-pascal wrote:
On 20/07/2026 16:19, Marco van de Voort via fpc-pascal wrote:
Op 20-7-2026 om 15:13 schreef Adriaan van Os via fpc-pascal:
So popen/pclose are a more high level (FILE * using) part of libc,
while we tend to only use the basis.
Ah, so that means that I couldn't just call naively into libc popen
with FileRec.Handle ?
Indeed. And FILE* is opague and thus target specific, it would
mean another structure to maintain, and to somehow to determine for a
new *nix target. STAT and STATFS already give us grief enough.
Right. So now I am calling PClose and it will hang. Why ? Well, PClose
calls WaitProcess in unx.pp, which in turn calls fpWaitPid in a loop,
which returns (on Darwin) 0 for a process that has died ....
repeat
r:=fpWaitPid(Pid,@s,0);
if (r=-1) and (fpgeterrno=ESysEIntr) Then
r:=0;
until (r<>0);
In general, I find such a loop, that depends on result codes, quite
risky. The POSIX standard says here
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html>
"If/wait/() or/waitpid/() return because the status of a child
process is available, these functions shall return a value equal to
the process ID of the child process. In this case, if the value of the
argument/stat_loc/is not a null pointer, information shall be stored
in the location pointed to by/stat_loc/. The value stored at the
location pointed to by/stat_loc/shall be 0 if and only if the status
returned is from a terminated child process that terminated by one of
the following means:"
This is nonsense. I apologize for the noise. The reason for the hang is
not the loop but the child process that has not terminated.
By the way, how do I flush the output to the POpen child process ? I
tried SysUtils.FileFlush with FileRec( File).Handle. but it failed.
Regards,
Adriaan van Os
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
