Thursday, August 5, 2010
Who said using Java isn’t any fun?
So, last week Eclipse broke because Oracle pushed a new update for Java that changed the company name field from “Sun Microsystems” to “Oracle”. The comments attached to a Slashdot story about the problem were merciless. Being predominently a Linux geek publication, the expected animus to Java in general was right out front. Here’s a sampling:
Lemme guess, you’re sweating bullets wondering if you’re going to spend all night pissing on fires while the C guys laugh at you and drink beer?
Sunday, May 23, 2010
Google custom search
Just added Google Custom Search to this blog, thereby addressing one of the biggest complaints I’ve gotten since the migration to Flatpress. Google Custom Search is a service offered by the web app megagiant for those who don’t have the time, intelligence or self-discipline to craft their own search engine. Because I fit into all three categories, implementing custom search on this site was really a no-brainer.[Read More…]
Friday, March 19, 2010
Regex for stripping all non-ASCII characters
This is important for me because I see a lot of creating formatting in directory entries, especially telephone number fields, that comes back to haunt me when exporting data for reports.
Of course it would be a lot better if the Netscape family of directory servers strictly enforced the schema when it came to phone number values, but unfortunately that train has left the station.
So here it is, a perl regex to strip any non-ASCII characters from an attribute value. I’ll use a cell phone number as an example.
my $mobile = $entry->get_value('mobile');
for($mobile) {
s/[^x20-x7Ex0Ax0D]/ /g;
}
Note that in this example I replace any of the offending characters with white space.
Thanks to the indomitable Mark Smith for this one.
Resources for learning Python
Python has been getting traction as a common programming lanugage for sysadmins. There are some people who think it could eventually supplant perl. As someone put it in a post to the python-dev list in 2005:
For me personally, one of the big reasons for jumping ship from perl to python (a considerable investment in time and effort) was to avoid perl 6. Its been clear for a long time that perl 6 will be completely different to perl 5, thus making perl 5 an evolutionary dead end.
My own assessment is that perl 5 isn’t going away any time soon. I think that once the main project jumps to perl 6 there will continue to be many people actively developing on the previous version and they might even fork into a new project. That’s almost certain to happen in the sysadmin community, where perl is still the most popular procedural language after the bash shell. Having said that, there’s considerable momentum driving many towards Python as mainstay scripting language.
Red Hat has been an active user of python as a foundation scripting language in their base distribution in places where perl or shell scripts were once dominant.
There’s a wealth of free online resources for learning the Python language.
First, be sure to visit python.org for the latest on Python.
Next, try out, The Python Tutorial
After that, in no particular order:
Monday, December 7, 2009
Sourcing an .env file from within perl
There’s lots of suggested solutions for this one all over the Internet. But that, as usual, is the problem. If you haven’t already guessed, the need to do this is an Oracle-driven thing. System administration of Oracle stuff invariably requires the “sourcing” of an environment file to set the system environment for some executable or script. Without adding module support for more sophisticated shell operations (e.g. Shell::Source), you’re going to have to use one of a number of methods to get there. Unfortunately most of those called upon to help out with this kind of problem have trouble with accepting it’s a necessary task (”Why do you want to do this?”), and so their solutions wind up being typically perlish and therefore … inelegant.
Here’s the scoop. To source an .env file and suck its results into your script, use an eval statement like this (where $envfile is a variable representing the full name and path of your .env, like “$HOME/oracle.env”):
eval {
exec ". $envfile; /usr/bin/perl -s $0 -env -- @ARGV";
} unless $env;
What this snippet does is set up an “-env” switch (defined by the “-s” option) that consists of the results flowing from the sourcing of $envfile. The “unless $env” prevents the script from going into an infinite loop. If you use the “strict” pragma, be sure to place this eval statement (and anything it depends on) above “use strict;”. Very clever, and something I could never have thought up on my own.
Here’s a different approach that requires some heavier lifting.