<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <br>

    <br>

    <div class="moz-cite-prefix">On 20/07/2026 19:56, Adriaan van Os via

      fpc-pascal wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:3ecc06c8-5929-4787-adb3-8109d5edf3a2@adriaan.biz"> <br>

      <br>

      <div class="moz-cite-prefix">On 20/07/2026 16:19, Marco van de

        Voort via fpc-pascal wrote:<br>

      </div>

      <blockquote type="cite"

cite="mid:1e42618f-b947-4f98-83ae-ed562439302d@pascalprogramming.org"> <br>

        Op 20-7-2026 om 15:13 schreef Adriaan van Os via fpc-pascal: <br>

        <blockquote type="cite">

          <blockquote type="cite"> <br>

            So popen/pclose are a more high level (FILE * using) part of

            libc, while we tend to only use the basis. <br>

          </blockquote>

          <br>

          Ah, so that means that I couldn't just call naively into libc

          popen with FileRec.Handle ? <br>

          <br>

        </blockquote>

        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. <br>

      </blockquote>

      <br>

      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

      ....<br>

      <br>

        repeat<br>

          r:=fpWaitPid(Pid,@s,0);<br>

          if (r=-1) and (fpgeterrno=ESysEIntr) Then<br>

            r:=0;<br>

        until (r<>0);<br>

      <br>

      In general, I find such a loop, that depends on result codes,

      quite risky. The POSIX standard says here

      <a class="moz-txt-link-rfc2396E"

href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html"

        moz-do-not-send="true"><https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html></a><br>

      <br>

      <span>    "If<span class="Apple-converted-space"> </span></span><i>wait</i><span>()

        or<span class="Apple-converted-space"> </span></span><i>waitpid</i><span>()

        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<span

          class="Apple-converted-space"> </span></span><i>stat_loc</i><span>is

        not a null pointer, information shall be stored in the location

pointed to by<span class="Apple-converted-space"> stat_loc.

        The value stored at the location pointed to by<span

          class="Apple-converted-space"> </span></span><i>stat_loc</i><span><span

          class="Apple-converted-space"> </span>shall be 0 if and only

        if the status returned is from a terminated child process that

        terminated by one of the following means:"<br>

      </span></blockquote>

    <br>

    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.<br>

    <br>

    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.<br>

    <br>

    Regards,<br>

    <br>

    Adriaan van Os<br>

    <br>

    <br>

  </body>

</html>