xopen : shell function to have verbose xdg-open : Mac's "open" alternative for Linux

I have been using xdg-open for sometime now, it's a utility similar to "open" utility popular among MacOSx users.

It enables you to open any file in the default "open with" program assigned to it's type. So, just passing any type of file to this utility would let you open it in the program it's supposed to open.

What is xdg-open?
source[1]: https://wiki.archlinux.org/index.php/xdg-open
source[2]: http://linux.die.net/man/1/xdg-open

There is just this little shell function, that makes your xdg-open usage a bit more verbose in case of errors (bad-syntax/ghost-file/ghost-program/open-failure) faced about the reason for it. And also shortens the access util name obviously.

xopen ()
{
    xdg-open "$@";
    _TMP_EXITCODE=$?;
    if [ "${_TMP_EXITCODE}" == "1" ]; then
        echo "[ERROR:] Error in command line syntax";
    else
        if [ "${_TMP_EXITCODE}" == "2" ]; then
            echo "[ERROR:] One of the files passed on the command line did not exist";
        else
            if [ "${_TMP_EXITCODE}" == "3" ]; then
                echo "[ERROR:] A required tool could not be found";
            else
                if [ "${_TMP_EXITCODE}" == "4" ]; then
                    echo "[ERROR:] The action failed";
                fi;
            fi;
        fi;
    fi;
    return $_TMP_EXITCODE
}

quick PuppetMaster Service Script for gem installed puppet set-up

On easy rubygem-way `gem install puppet` installation method for Puppet doesn't get you the *nix platforms service script... so here is one allowing you to perform Start||Stop||Restart||Status service task for puppetmaster.

• Save the file below as '/etc/init.d/puppetmaster'
  $ sudo curl -L -o /etc/init.d/puppetmaster https://gist.github.com/raw/2479100/15f79c68be3f6f6bf516adf385aac1f29f802a45/gistfile1.rb
• and turn on its eXecutable bit
  $ sudo chmod +x /etc/init.d/puppetmaster
• Now you can use it as
  $ service puppetmaster status

PuppetMaster Service Script

mysql-server retained old credentials, got work-around but no solution

While trying re-configuration of an existing  mysql-server over CentOS, tried 'yum remove' the mysql-server and then again 'yum install' it.

When I tried setting up a new password for 'root' using 'mysqladmin', it raised an error. Some random troubleshooting showed it still had earlier-installation's root credential working for it.

Trying some more stuff, I manually set 'old_password=0' in '/etc/my.cnf' and then tried re-installing. It still had the earlier password working for it.

For time being, got a work-around fixing the problem... 

$ yum erase mysql mysql-server
$ rm -rf /var/lib/mysql
$ yum install mysql mysql-server
$ service mysqld restart 

The location of user's information i.e. the user table data resides in '/var/lib/mysql/mysql/user.MDY'; but just removing that only file wouldn't work because it don't get recreated on re-installation if entire directory structure is present.

A service restart is required to create a vanilla copy of '/var/lib/mysql'. 

Still... the issue exists of why to do it manually.

The incidence is under discussion at the link below. If you have a non-hackish solution for the problem or could spot the actual mistake, please reply there.

http://stackoverflow.com/questions/6606869/mysql-retains-password-of-earlier-installation-even-after-proper-yum-remove