Archive for May, 2006

Bash socket programming with /dev/tcp

Tuesday, May 23rd, 2006

Today I discovered a nifty way to do socket programming in bash without the need for netcat (nc) or telnet: /dev/tcp. Say you want to connect to Google and fetch their front page. Just do this:

CODE:
  1. exec 3<>/dev/tcp/www.google.com/80
  2. echo -e "GET / HTTP/1.1\n\n">&3
  3. cat <&3

I found this very handy when trying to connect to a host and read some info from a socket, but I wanted to do it all in a few lines of bash. This is great, because you don't have to worry about what version of Python or Perl your users will have. If they've got bash, you're set. There is one caveat: some systems (Debian included) don't enable /dev/tcp. I don't know why, but they don't. So make sure your target system has it before coding this up. Oh, and you can use /dev/udp too if you really want to spice things up!

Where does this come from? It turns out it's a pure bashism, which has to be enabled when you compile bash. Bash actually intercepts "/dev/tcp" and provides special behavior, so you're not actually opening a device node called /dev/tcp. Pretty cool, eh?!

Happy bashing!

PHP: The @ Operator

Sunday, May 7th, 2006

I've seen some confusion online lately about the purpose of the "@" operator in PHP. Let's figure out exactly what the "at operator" does.

PHP holds your hand with error reporting during development by printing error messages to the user's browser automatically when something goes wrong. This often looks something like this:

Warning: mysql_connect() [function.mysql-connect]: Unknown MySQL server host 'woopsy.example.com' (1) in errors.php on line 3

The code that created this warning looks like this:

PHP:
  1. mysql_connect( "woopsy.example.com" );

Pretty simple -- I tried to connect to a non-existent MySQL server using a mistaken hostname. This is handy, but I usually don't like these kinds of errors to show up when a user browses my site. We can make the error go away by prepending a "@" on the front of the call to mysql_connect(), like this:

PHP:
  1. @mysql_connect( "woopsy.example.com" );

This gets rid of the warning message we saw earlier, but now we have no way of knowing whether mysql_connect() was actually able to connect or not. To fix that, we need to check the return value. According to the mysql_connect() documentation, the function returns a MySQL link identifier on success and FALSE on failure. So, let's do this:

PHP:
  1. $db = @mysql_connect( "woopsy.example.com" );
  2. if( $db === false )
  3. {
  4.    echo "Could not connect to server.";
  5.    exit();
  6. }

The lesson to take away from this is that the "@" operator suppresses error messages, not return values. You can read more about the operator at the PHP Error Control Operator documentation page.

For the motivated reader, the "@" operatore has many more applications. You can use it to suppress errors in include files and even bad array indexes.

The best way to deal with errors, however, is to use your own error handling function by calling set_error_handler() . This way, you can get notified whenever an error occurs, and you can even be told the error number, message, file, and line number. This way you can log it or even present a link for users to report the bug. It's very handy, and a great way to find and fix bugs without requiring too much user inconvenience.

The phpLDAPadmin project has an excellent implementation of an error handler, which can be viewed here. Search that page for pla_error_handler. It reports lots of versions (ie, the web server and PHP version), the exact error message, and even some PHP settings. It proved very useful for users to report bugs, since they could just copy/paste the output on the SourceForge bug tracker. '

This leads me to my final comment. I've already mentioned that the best way to handle errors in PHP is to implement your own error handler and call set_error_handler(). In this function, you should log all errors, and then only display a message for those that happen without the "@" operator present. In other words, you should do something like this:

PHP:
  1. function my_error_handler( $errno, $errstr, $file, $lineno )
  2. {
  3.    my_log_msg( "Error $errno: $errstr in file $file on line $lineno" );
  4.  
  5.    if( 0 == ini_get( "error_reporting" ) || 0 == error_reporting() )
  6.       return;
  7.  
  8.    // Display an error message of some kind
  9. }

Any now my final comment: I use error_reporting() in all my PHP applications to set the strictest error reporting possible like so:

PHP:
  1. error_reporting( E_STRICT );

You may not want such strict error reporting in your application, so choose from the available error levels. This will give you all kinds of error messages, but it will help you bullet-proof your code in a jiffy.

Enjoy your error reporting!

SpeedScheduler featured on Digg (sort of)

Tuesday, May 2nd, 2006

SpeedScheduler, a little Azureus plugin that I wrote a while back, was featured in an article that made Digg's front page: Top Azureus Plugins Revealed. Scroll to the bottom of the article for a few screenshots and a little write up. That's pretty nifty.