This post was partially inspired by half an hour of unsuccessful googling in trying to figure out how I should be getting into a shell as another user with no password required. The other part of the inspiration came from the responses to this tweet where I was inspired to dig deeper about these ubiquitus shell commands. I use sudo/su almost every day with no deep understanding of what it does, and I figured it was time to change that.

The differences between these three possible ways to enter a shell as different users were not apparent to me at all, and I’m pretty sure that other people share my confusion or misunderstandings.

The su command lets any user change their user id and start a shell as another user. With no extra arguments, as far as I can tell su <username> is exactly the same as attempting to login remotely as that user, but preserves the environment variables set from the original shell. You are prompted for a password, that is the password of the user that you are attempting to change into. The exception to this behavior is if you are already logged into the shell as root. If you are already root, no password is requested.

The sudo su command has similar behavior to su, but it changes which password you have to enter, if any. This command requires you to use sudo, which means that the su command will be running as root. As described earlier, if su runs as root, you will not need to enter the target user’s password.

Now the question is, how can you run sudo. This depends on how your user has been configured in the /etc/sudoers file. There are many tutorials that you can find about how that file works, how it’s formatted, and what options are available, but, in my case, there was only one consideration. My user had the NOPASSWD option set, so I do not have to use a password in order to sudo. If you did not have that option set, you would have to enter a password in order to use sudo, but it would be your own password, not root’s nor the target user’s.

Additionally, I used the word similar earlier because sudo su does not preserve the environment variables of the original shell.

The sudo -u <user> -i command is what you need to run if you want to simulate precisely the initial logged in state of another user. The -i option is supposed to stand for simulate initial login. It will create the proper shell, source .bashrc/.bash_profile files, and drop you into the target user’s home directory. The only use that I can see for this is, as a system administrator, debugging issues that are user specific. So far, I have not needed it.

---

In this exercise, I found that sudo su was the right option for me to achieve my desired effect. I could sudo su to the user I wanted to be, and no password was required.

There is a lot more to learn about these commands, aside from the particular options that I’ve described here. Reading through the man pages, there are many possible configurations that more precisely control environment variables, which shell to start with, and many other things. I haven’t yet found a reason to use all of them as a programmer, but they’re definitely good to know.

Follow me @johnkpaul

See you in the comments!

References:

• man sudo
• man su
• Sudoers Manual
• Understanding and using sudo in Unix or Linux (with examples)

Within the past few weeks, A List Apart came out with an article about the pixel identity crisis. There’s a lot of buzz around the hardware pixel vs the device specific reference pixel and whether or not CSS media queries and device-pixel-ratio can help. I read through that article and realized that it did a really good job at explaining the concepts. Since I’m not a mobile developer at my day job, I haven’t needed to delve very deeply with these issues, but I have had one common itch to scratch.

In most of my desktop web work, I need to at least make the pages that I develop look and behave decently on the iPad/iPhone, if not a wider variety of mobile devices. The boiler plate that I need to worry about is usually the viewport metatag, which has the potential to be very confusing. I haven’t yet found a good tutorial that made initial-scale make half as much sense as pixel ratios do in that ALS article, so here it goes.

The <meta name="viewport"> tag has a content attribute with many different options such as width, min/max-scale and initial-scale.

Width is the most straightforward. It specifies the number of pixels wide that the content of the page is intended to be. If max/min/initial-scale is specified, this is really being used as a minimum viewport width. No matter what, the device user will be able to scroll to see at least this amount of pixels.

Scale on the other hand, takes a little bit more of an explanation. In these explanations, I will be using this 1280x960 image. The image is made up of 10px by 10px squares.

The way that I make sense of scale is with an equation. This equation has 3 variables.

• D = The actual device width, in hardware or reference pixels (320)
• S = The scale value itself (1)
• N = The number of pixels of content actually displayed on the device

The equation that we can use to express the relationship between these number is.



When the initial scale is set to 1, only 320 pixels of the 1280 total width image are displayed. This is because the width of the iPhone device is 320 pixels and 320/1 = 320.



When we double the initial scale, to 2, only 180 pixels are displayed at first.



When the initial scale is reduced to .5, 640 pixels are displayed.



And finally, when the initial scale is reduced to .25, 1280 pixels are displayed.

These images only show initial scale, in order to show how many pixels are displayed at different scales.

A more important lesson from this, is how to use max and minimum scale. If I were to set minimum-scale=.50 in my viewport metatag, my user would never be able to get a closer look than 640 pixels per full portrait width. Personally, I find this always obnoxious when I come across it myself, but I am sure that there are valid uses of it.

Along the same vein. if you set maximum-scale=1, your user would be unable to view more than 320 pixels of width at one time, and they would be forced to pan around to see all of the content.

Lastly, although the example that I am using here is a iPhone, all of this math works out exactly the same for the myriad mobile devices out there.

I’d love to hear what you think in the comments. Also, you can follow me @johnkpaul

After looking around online, attempting to sharpen my google-fu, I couldn’t find any real cross browser implementations of getComputedStyle().getPropertyValue().

I was able to find two options, both of which make the same mistake when it comes to camel casing of properties in < IE9.

Sadly, IE expects the camel cased version of the CSS property name, i.e. “marginTop” instead of “margin-top”. Every other browser that supports window.getComputedStyle or document.defaultView.getComputedStyle, uses the hyphenated syntax. I have chosen to have this script expect hypenated css properties, but it could easily be extended to accept either format.