Subentry of PHP-GTK

Why Is proc_open() Not Fixed Yet?

Wed12Dec2007

I am referring to this PHP bug where the proc_open() ability to use system PTY's was disabled because of a bad "configure check". It has been over a year already.

 

 

Why am I complaining though? Because PTY is the only way to enable the reading of STDOUT of child processes from background processes. This example code is in my radio.phpg file.

 

$pp = proc_open(
      "mplayer '{$url}'",
      array(
            array('pipe','r'),
            array('pipe','w'),
            array('pty','w')
      ),
      $pipe, null, null
);

 

 

// read stdout
Gtk::io_add_watch(
      $pipe[1],
      GObject::IO_IN,
      array($this,'on_player_output')
);

 

Any idea why `./radio.php` works and `./radio.phpg &` does not? Because forcing it into the background it never connected to a STDIO stream, I guess. Why is this important? Because if you were to launch radio.phpg from your window manager 'Run Command' it would fail to read mplayer's output.

After manually enabling this PTY bit in the PHP source, the following code works no matter if radio.phpg is background or not.

 

$pp = proc_open(
      "mplayer '{$url}'",
      array(array('pty'),array('pty'),array('pty')),
      $pipe, null, null
);

 

 

user posted image

 

It works because it actually creates a pseudo-terminal entry in the system to connect STDIO streams to.

 

Before proc_open
//. bob@elenothar [bob]$ ls /dev/pts
2

After proc_open

//. bob@elenothar [bob]$ ls /dev/pts
0 2

After closing the terminal I launched radio.phpg & with

//. bob@elenothar [bob]$ ls /dev/pts
0