title: get output from shell_exec command as command runs
body: <p>I am coding a PHP-scripted web page that is intended to accept the filename of a JFFS2 image which was previously uploaded to the server. The script is to then re-flash a partition on the server with the image, and output the results. I had been using this:</p>
  
  <pre><code>$tmp = shell_exec("update_flash -v " . $filename . " 4 2&gt;&amp;1");
  echo '&lt;h3&gt;' . $tmp . '&lt;/h3&gt;';
  
  echo verifyResults($tmp);
  </code></pre>
  
  <p>(The verifyResults function will return some HTML that indicates to the user whether the update command completed successfully. I.e., in the case that the update completes successfully, display a button to restart the device, etc.)</p>
  
  <p>The problem with this is that the update command takes several minutes to complete, and the PHP script blocks until the shell command is complete before it returns any of the output. This typically means that the update command will continue running, while the user will see an HTTP 504 error (at worst) or wait for the page to load for several minutes.</p>
  
  <p>I was thinking about doing something like this instead:</p>
  
  <pre><code>shell_exec("rm /tmp/output.txt");
  shell_exec("update_flash -v " . $filename . " 4 2&gt;&amp;1 &gt;&gt; /tmp/output.txt &amp;");
  echo '&lt;div id="output"&gt;&lt;/div&gt;';
  echo '&lt;div id="results"&gt;&lt;/div&gt;';
  </code></pre>
  
  <p>This would theoretically put the command in the background and append all output to /tmp/output.txt.</p>
  
  <p>And then, in a Javascript function, I would periodically request getOutput.php, which would simply print the contents of /tmp/output.txt and stick it into the "output" div. Once the command is completely done, another Javascript function would process the output and display a result in the "results" div.</p>
  
  <p>But the problem I see here is that getOutput.php will eventually become inaccessible during the process of updating the device's flash memory, because it's on the partition to which is targeted for an update. So that could leave me in the same position as before, albeit without the 504 or a seemingly eternally-loading page.</p>
  
  <p>I could move getOutput.php to another partition in the device, but then I think I would still have to do some funky stuff with the webserver configuration to be able to access it there (a symlink to it from the webroot would, like any other file, eventually be overwritten during the re-flash).</p>
  
  <p>Is there any other way of displaying the output of the command as it runs, or should I just make do with the solution I have?</p>
  
  <p><strong>Edit 1:</strong> I'm currently testing some solutions. I'll update my question with results later.</p>
  
  <p><strong>Edit 2:</strong> It seems that the filesystem does not get overwritten as I had originally thought. Instead, the system seems to mount the existing filesystem in read-only mode, so I can still access getOutput.php even after the filesystem is re-flashed.</p>
  
  <p>The second solution I described in my question does seem to work in addition with using popen (as mentioned in an answer below) instead of shell_exec. The page loads, and via Ajax I can display the contents of output.txt.</p>
  
  <p><del><strong>However</strong>, it seems that output.txt does not reflect the output from the re-flash command in real time-- it seems to display nothing until the update command returns from execution. I will need to do further testing to see what's going on here.</del></p>
  
  <p><strong>Edit 3:</strong> Never mind, it looks like the file <em>is</em> current as I access it. I was just hitting a delay while the kernel did some JFFS2-related tasks triggered by my use of the partition on which the source JFFS2 image is stored. I don't know why, but this apparently causes all PHP scripts to block until it's done.</p>
  
  <p>To work around that, I'm going to put the update command invocation in a separate script and request it via Ajax-- that way, the user will at least receive some prepackaged feedback while technically still waiting on the system.</p>