Here’s the tricky part. As we know from the exec() man page this function executes the given command. As described there, the exact declaration of this method is:

string exec  ( string $command  [, array &$output  [, int &$return_var  ]] )

So far so good. Normally exec() will return the output of the command.

FFmpeg version SVN-r21880, Copyright (c) 2000-2010 Fabrice Bellard, et al.
  built on Feb 18 2010 15:53:28 with gcc 4.3.2
  configuration: --enable-gpl --enable-nonfree --enable-shared --enable-postproc --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-x11grab --enable-bzlib --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3 --enable-libdc1394 --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libgsm --enable-libmp3lame --enable-libschroedinger --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-zlib --prefix=/usr/local
  libavutil     50. 9. 0 / 50. 9. 0
  libavcodec    52.54. 0 / 52.54. 0
  libavformat   52.52. 0 / 52.52. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libavfilter    1.17. 0 /  1.17. 0
  libswscale     0.10. 0 /  0.10. 0
  libpostproc   51. 2. 0 / 51. 2. 0
...

However sometimes that is not so true. Let’s see an example with the popular FFMPEG program. In one hand when you try to start a video converting program with PHP you can simply call exec with the FFMPEG command as the first parameter. The output is OK and you can dump it as in the example here.

echo exec('/usr/local/bin/ffmpeg -i input.mp4 -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre normal -threads 0 output.mp4', $output);	
var_dump($output);

In some cases you can call FFMPEG only with the -i option to get some info about the input file. Such info can be the size of the image, the bitrate of the source file or the length of the movie. Executing this command:

echo exec('/usr/local/bin/ffmpeg -i input.mp4', $output);	
var_dump($output);

in the terminal you’ll see the output you wish. However if you trying to execute the command via exec() the output remains empty?

Why the Output Parameter is Empty?

Looking at the terminal screen you can’t see the difference, but actually in the second case, when you execute FFMPEG only with the -i option, the output is redirected to the standard error output. That’s why you can’t see it in the exec() second parameter. However there is a solution.

Solution and Conclusion

The solution is quite simple. You’ve to redirect the output of the FFMPEG command to the standard output.

/usr/local/bin/ffmpeg -i /var/www/android/test.mp4 2>&1

Now you can call this line with exec().

echo exec('/usr/local/bin/ffmpeg -i input.mp4 2>&1', $output);	
var_dump($output);

This showcase with the FFMPEG is important not only because now you can call FFMPEG’s command without problems, but because you now know that exec() can’t read the standard error output. Thus you’ve to be careful and always redirect to the standard output.

After Node.js is istalled, described in my previous post, I can simply run this command:

stoimenpopov:~# node server.js

and this will start the server with the code within server.js. But what’s the code of server.js?

Following the instructions of Node’s homepage and most of the tutorials I’ve found, I can simply copy/paste the code from the first lines of Node’s page:

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

There are several things I find interesting in this code, making it different from JavaScript as we know it. First of all what is

var http = require(‘http’)

and why I need it? What is the purpouse of 8124 and 127.0.0.1?

Node is built in modules and to use one of them you must first include it with require. Just like the example above with require(‘http’). In the same manner you can include every module of Node.

What are the Node’s modules are pretty well described in the API page. Well I’d like to say that the API page is quite insufficient. That is very bad, cause most of the code you’ll need developing a node.js applicatoin isn’t described/explained there.

However is more than obvious that 8124 is the port, while 127.0.0.1 is the IP address of the server, which in this case is the localhost. Thus after running the server and typing http://127.0.0.1:8124/ into your browser you’ll get “Hello World”. This is not enough when the server is running on a remote machine, while you’ve to access it from your local computer.

The first server

As I described the code above shows you an example server. In fact the API page shows a slightly different code:

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello World\n');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

Here the line:

}).listen(8124);

omits the address of the server. It appears to be non-required and the server is supposed to listen on this machine on the given port. To be honest I’m not sure why you’ve to write the server address, except for limit the possible address to this one. However in my case the server was installed on a remote machine indeed, while I was trying to access it from my local machine. So here are some base steps to do before accomplishing this.

1. Changing the IP address

First of all you can omit the IP address. This can help you move the code from one server to another without changing the code.

}).listen(8124, ip_address);

possibly a better solution is:

}).listen(8124);

Node can listen on whatever port you say so this is up to you to decide which port should be opened.

2. Opening the port

While everything’s on the localhost you wont have problems with port opening. If you’d like to access it remotely however, you’ve to open the port. In other words http://127.0.0.1:8124/ is OK without port opening, but http://example.com:8124/ – is not!

To open a port in UNIX/Linux you’ve to type this command in the terminal:

iptables -A INPUT -p tcp --dport 8124 -j ACCEPT

don’t forget to change the port number from 8124 to whatever port number you’re using.

3. The first AJAX call

We still cannot make the first AJAX call to the Node server. Here I’m using jQuery because of the easy AJAX interface.

$(document).ready(function() {
	$.ajax({
    	// setup the server address
        url : 'http://example:8124/',
        success : function(response) {
        	// on success
        	alert(response);
		},
        error : function() {
        	// on error
        }
    });
});

After executing this code in a browser there wont be a response. That is because of the remote AJAX calls restriction. To overcome this you’ve to change the returned header from the Node’s server, by adding this:

'Access-Control-Allow-Origin' : '*'

Now server.js will look like this:

var http = require('http');

http.createServer(function (request, response) {
	response.writeHead(200, {
		'Content-Type': 'text/plain',
		'Access-Control-Allow-Origin' : '*'
	});
	response.end('Hello World\n');
}).listen(8124);

you can now either load http://example.com:8124/ into your browser or to make the AJAX call. In both cases the answer will be “Hello World”

Summary

Now you have a very simple Node.js server. Well it is nothing special as it responses with “Hello World” on every request, but it works remotely.

Soon I’ll describe how to change the server so it can waits to respond until some event is emitted – which is the real power of Node.js.

The one thing I couldn’t find in the man page of Zend Server CE is how to I access this MySQL server installation from my PHP scripts.

The answer is quite simple – trough UNIX socket. The ZS CE default db socket is:

/usr/local/zend/mysql/tmp/mysql.sock

and yet again let me say that this is for Mac.