Why switch to root ?

When in a shell as a non-root user, you have to use sudo to execute a command which requires root privileges e.g.:

sudo chown henribenoit:_www *

That’s the clean way of doing it: use a non-root user and only use sudo when required. But sometimes it just drives me crazy to prefix most commands with a sudo and I’d just rather switch to the root user, do all I need to do and then switch back.

The alternatives

There are a couple of ways to do this:

• sudo -i
• sudo su
• sudo -s
• sudo bash

All of them will allow you to switch to the root user but give you an environment more or less mixed with the previous user’s environment. Let’s see what each of these commands actually does.

In the sections below, I’ll execute the following command after switching to root with the respective commands:

env | grep "SHELL=
USER=
PATH=
PWD=
HOME=" | grep -v OLDPWD | sort -u

When running it before switching to root, I do get:

HOME=/Users/henribenoit
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/henribenoit
PWD=/Library/WebServer/Documents
SHELL=/bin/bash
TESTPWD=/tmp
USER=henribenoit

Note that I’ve updated the PATH adding the directory /Users/henribenoit to check whether the PATH is being reset and I’ve also added a dummy environment variable TESTPWD to check whether it’s still in there after switching to root. I made these 2 changes executing the following:

export PATH=$PATH:/Users/henribenoit
export TESTPWD=/tmp

sudo -i

Of all four options, sudo -i is the one which will give you the purest environment.

Running the command above, you will get:

HOME=/var/root
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/henribenoit
PWD=/var/root
SHELL=/bin/sh
SUDO_USER=henribenoit
USER=root

So it did take over the PATH I had defined before switching users but changed the home directory, the current directory, the shell used and the current user. Also the additional dummy variable was not taken over.

sudo su

Running the command above after using sudo su, returns the following:

HOME=/var/root
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/henribenoit
PWD=/Users/henribenoit
SHELL=/bin/sh
SUDO_USER=henribenoit
USER=root

Here the PATH and the current directory were not changed after switching to root. The rest was changed and the dummy variable is also not present anymore.

So the difference between sudo -i and sudo su seems to be that sudo -i additionally changes the current directory.

sudo -s

This command takes over even more of the environment before the user switch:

HOME=/Users/henribenoit
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/henribenoit
PWD=/Users/henribenoit
SHELL=/bin/bash
SUDO_USER=henribenoit
USER=root

So the home directory, the path, the current directory and the shell did not change after using sudo -s. So only the current user was changed to root and the dummy variable is not available anymore.

The difference between sudo su and sudo -s is that the latter does not change the shell and home directory.

sudo bash

This one gives you the exact same environment as the previous one:

HOME=/Users/henribenoit
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/henribenoit
PWD=/Users/henribenoit
SHELL=/bin/bash
SUDO_USER=henribenoit
USER=root

Even if you check all variables returned by env, you will see that there is no difference.

Which one to use ?

As always, it depends on what you will do after switching to root.

Changing the home folder will:

• change the command history you are accessing
• have an impact on some program installers

I usually do not have an issue with installers referencing the HOME directory. But in some cases I find it useful to keep the history I had with the previous user. In this case, I rather go for sudo -s or sudo bash.

Obviously using a different shell will force you to potentially use a different syntax. That’s why I only use sudo su if I need to the HOME directory to change to root’s home directory.

If you’ve already navigated to the directory you want to work in, the you shouldn’t use sudo -i as it will change the current directory. If it’s the first command you run after opening a shell, the it probably doesn’t really matter.

So in most cases I do use sudo -s (it’s 2 characters shorter than sudo bash ;-)) and in some rare cases sudo su. I personally never use sudo -i (anyway keeping sudo -s and sudo su in mind is already a lot for my small brain and remembering a third option will cause some overflow…).

And remember the additional password check which gets on your nerve when prefixing your commands with sudo once in a while might save you some day (especially if you start cleaning up files early in the morning before even having your first coffee of the day). So only switch to the root user if you really have to. Otherwise execute all commands you can with another user and only the ones which need root privileges with the root user.

Most website have many images. You might not be aware of it but it does. I mostly have text and code in my posts and thought I do not need to care too much about optimizing the images in there because there are rarely any. But the fact is that even though my posts mostly do not contain images, the theme I use as well as a few plugins do use images.

If you are using WordPress, you can easily optimize (and compress) images in your post using a plugin. I’ve used WP Smush.it and EWWW Image Optimizer. First I used WP Smuch.it but at some point in time it stopped working so I switched to EWWW Image Optimizer. But when WP Smush.it got fixed I switched back since I felt more confortable with it.

But these plugins only optimize images in the media library. Not images part of themes or plugins. Since most images on my site fall under this category, I had to find a solution. I didn’t find a plugin for this but two nice command line tools.

Why two ? Well because one of them takes care of PNG files and the other one takes care of JPEG files.

First, the PNG files. I optimize them using a command line tool call optipng. You can install it like this under Linux:

apt-get install optipng

(note that you might need to add a sudo before the apt-get)

On Mac, using Homebrew:

brew install optipng

To use the tool, you just need to provide a file to optimize:

optipng myfile.png

If you need to optimize all images in a given folder:

find . -iname "*.png" -exec optipng {} \;

If you want an even better optimization and can leave with a very long optimization duration, add the -o7 Option:

find . -iname "*.png" -exec optipng -o7 {} \;

Now, the JPEG files. For this I used a command line tool called jpegoptim.

Installation under Linux:

apt-get install jpegoptim

On Mac with Hombrew:

brew install jpegoptim

And just provide a file to optimize:

jpegoptim myfile.jpg

For a bulk optimization:

find . -iregex ".*\.jpe?g" -exec jpegoptim {} \;

This performs a lossless optimization (this means the pixels you’ll see are still the same but the file is smaller). Without loss of quality you can still get smaller file but if you can live with a lower image quality, you can achieve a better optimization:

find . -iregex ".*\.jpe?g" -exec jpegoptim --max=75 {} \;

This means you are ready to loose up to 25% quality in order to get smaller files.

Note that you can also optimize images online using Smush.it.

Also remember if you use WordPress that images in plugins and themes will be overwritten by every update of the plugin or theme. So run these two tools once in a while (at least after updating multiple plugins and themes).