Web Conferencing - Video Conferencing - Net Meeting : Raindance
Like WebEx.

Perl::Whitespace

$line =~ s/^\s+//; is supposed to get rid of all whitespace characters at the beginning of a line. I have been messing around for white a bit now scratching my head about why this is not working for me.

Finally I open the text file "as binary" to see the HEX codes for each character and I find that the "spaces" at the beginning of this line of my data file are NULL, that is "ASCII code" = zero.

So, NULL must not be defined in Perl as "whitespace." I assume it will only match the "blank" characters that have their own special escape character like \t \n and "space" (ASCII 32, HEX 20.)

Well I replaced s/^\s+//; with s/^\x00+//; and life is now good.....

If you read this (and I know at least a few of you are out there) leave me a comment if you can confirm what Perl defines as "whitespace" when matching on \s.

Windows XP::Task Scheduler::Network

Trying to get a "listener" program to run at startup from task scheduler. (this thing won't run as a service after all the messing around I've done trying that.)
Scheduler is acting weird on this imaged machine. It is not allowing me to "browse" to an EXE it only presents the registered applications. I can drag an EXE onto it but it won't let me edit the command line or input a "startup folder" which is blank and greyed out. And it just plain won't work.
After a long day I finally have it:
- got JT.EXE from Microsoft -- very user un-friendly. ftp://ftp.microsoft.com/reskit/win2000/jt.zip

- found JTRUN.VBS that provides a more usable front end to JT.EXE at http://www.windowsitpro.com/WindowsScripting/Article/ArticleID/45148/45148.html

- modified and used the above to create a task on that machine with the correct startup folder. (My listener reads a parameter file from the current directory to determine what port to listen on.)
- setup the task to run logged on as a user with appropriate domain and local permissions.
- made exception in XP firewall for the listener. This allowed access locally, but not remotely. I actually had to make a port exception for that incoming port. I think this is because the listener forks a process to listen on the port. (this allows it to have more than one subsequent connection instead of closing down after a single connect session.) And I think the firewall exception is somehow now applying to the child process of the same name.