I just discovered this very cool tip. If you want a colored man pages, adding the following to your environment does it:
export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'
I found the tip while searching for a way to preserve the colored output of grep after it has been piped into less. ‘less -r’ preserves the terminal escape sequences from the input. The following will get preserve the colors:
grep --color=always <search_term> | less -r
While searching for information about a particular Perl command line option, I ran accross an excellent page of Perl one-liners. Many of these are very practical uses for perl in daily tasks. I figured I would link to them here in hopes that they are useful to somebody else.
In several current projects I have been working on AJAXifying old systems and building new systems with AJAX components. Though I have tried to take advantage of open libraries such as prototype.js and Open Rico, I have yet to find a good framework that incorporates both the server-side and client-side programming needs. So, upon hearing news about the Open Ajax coalition of BEA, Borland, the Dojo Foundation, Eclipse Foundation, Google, Laszlo Systems, Mozilla, Novell, Openwave, Oracle, Red Hat, Yahoo, Zend, and Zimbra, naturally I got excited.
This could finally lend the kind of stability and formality to the technology that would aleviate many of my current headaches as a developer and many of the criticisms from users. The awesome thing about AJAX is that it is built on non-proprietary technologies unlike any of the other leading rich client technologies; thus, if it could be developed in a manner that gives it the same formality and maturity of other web standards, such as HTML and XML, it would go a long way toward simplifying development, cutting costs, and improving user’s experiences. I believe the companies backing it have the experience and sway to make it happen.
In a recent project, I am using a java daemon to manage and pool connections to an XML service I am using. If the connection fails, the daemon automatically closes the socket and reconnects. This was working great until one day the IP addresses for the service changed. Though TTL for the dns lookup had run out and the local dns properly found the new IP’s, the connection pool was still not able to make connections until the JRE and daemon were restarted.
I thought this was really weird, and did some research. It turns out that Sun’s JRE has it’s own dns cache that defaults to "cache forever." Though, I think this is a really bad default behavior, they do provide a way to fix it. It turns out there are some properties that can be set on the command line to change it as documented in their Networking Properties manual. If you pass a -Dsun.net.inetaddr.ttl to the JRE commandline with the number of seconds to cache, that should fix it. Sun’s argument for having this default value is to hedge against DNS spoofing attacks, but if you consider your dns to be relatively secure, it can be just an annoyance.