Get Growl Notifications on VNC connections, SSH attempts, and HTTP logs [solved]

Use this script to monitor VNC connections with Vine Server:
nice -n 100 tail -n 0 -f /Users/jordan/Library/Logs/VineServer.log | php -r 'while ($m = fgets(STDIN)) shell_exec("growlnotify -p 0 Vine Server -m ". escapeshellarg($m));'

Change “jordan” to your username (home directory), or the whole path of the log if you’re monitoring something else. “Vine Server” is the alert title, which could be anything (“Hello World”).

Save this as a file such as Run
chmod 755
and then you can run the command by typing ./

Duplicate this file and name it vinenotify.command.
Finally, in System Preferences > Accounts > Start up items, add vinenotify.command, and make it hidden, and it will run when you log in.

Things I’m still working on: preventing a string of notifications when you launch VNC; hiding the terminal window when you log in; and grepping for only connect/disconnect/login failures.
Thanks to for the growl tail code.

Choose a random winner or randomize a list with terminal and PHP [solved]

I wrote this for my class, which needed to have a randomized order of presentations:

php -r '$order = array("person1","person2","person3","person4","person5","person6","person7","person8","person9","person10");shuffle($order);foreach($order as $number=>$name){echo $number+1 . " $name\n";}'

To run it, open up terminal (in OS X) and paste it in.

I’ve also had to choose a random winner for gift certificates before:
php -r '$order = array("person1","person2","person3","person4","person5","person6","person7","person8","person9","person10");shuffle($order);echo "$order[0]\n";'

Comet with PHP 4 [solved]

I’m beginning to work with comet (an ajax-like technology that uses a single connection with multiple server pushes) and found this tutorial extremely helpful:

However, I had to modify the code slightly to work with PHP 4, which doesn’t support json_encode. Instead I just returned the json array manually:

// return a json array
//$response = array();
//$response['msg']       = file_get_contents($filename);
//$response['timestamp'] = $currentmodif;
//echo json_encode($response);
echo "{&92;"msg&92;":&92;"" . file_get_contents($filename) . "&92;",&92;"timestamp&92;":" . $currentmodif . "}";

I don’t know enough french to navigate or comment on Zeitoun’s site so I thought I’d at least publish this here.

Hmm, my code markup plugin seems to be deleting backslashes. I tried replacing them with &92; but they just look like &92;. So replace all &92;s above with \.

Deal with Word characters in ISO-8559-1 [solved]

I spent way too much time on this, trying all sorts of solutions, for how easy it finally was to solve. I want to list everything I tried though first so others having this same problem might find this post.

I have a new programming gig. I was assigned a bug where the application we’re using generated a SOAP fault if a user pasted content from a Word doc into a form. The SOAP call specified ISO-8559-1 as the character set that it uses, and Word evidentially uses another character set. I tried changing the call to UTF-8 but it didn’t help.

Using ord() in PHP to get the character numbers of the bad characters, I detected that the nasty characters included chr(145), chr(146), chr(147), chr(148), chr(133), chr(150), chr(151), chr(210), chr(211), chr(128), chr(153), chr(156), and chr(157). These are the stupid “smart” or “balanced” quotation marks, left and right single and double quotes, em dashes, en dashes, and elipses (three dots …) .

However, I was unable to find and replace these characters using a variety of methods. It turned out the encoding from Word was in Windows-1252, which is a multibyte encoding that str_replace isn’t going to find when using chr().

I tried mb_check_encoding but it didn’t work, possibly because it wasn’t supported on my server. I tried iconv() but it kept giving me “illegal character” and “cannot convert encoding” errors. Frustratingly, iconv did not honor the //TRANSLIT and //IGNORE flags as documented on, which were supposed to convert or ignore the bad characters automatically.

I did find a preg_replace function on the comments of iconv on that stopped the soap faults by converting all bad characters to question marks, but the question marks wouldn’t have satisfied the client, and on continuous re-edits the question marks doubled and tripled themselves.

Finally, I found the answer here:
(BTW, when did they open up the webmasterworld forums again? They’ve been locked for like a year. Sweet!)
It turns out if you add an accept-charset=”UTF-8″ flag in your input form tag, the browser will do all the character conversions for you automatically before it even reaches the PHP, SOAP or Java. Even though my SOAP call was in ISO-8559-1, UTF-8 passes through fine and all of the weird word gremlins remain unchanged.

—–  ©®™…‘’“”