Skip to content

Mastering the Unix Terminal: Working With Permissions, Networking, and Other Key Concepts

Last time we covered Unix commands, we talked about how you can move around the filesystem from the command line. These ideas are crucial; if you don’t understand the basics of navigating files and folders from the terminal, there’s not a lot you can do on the command line. If you’ve not mastered that, start with this on file-manipulation from the command line.

Once that’s under control, you want to understand the commands that change the way files and folders act. In this article we’ll cover the rest of the stuff I regularly do on the command line. We’ll explain permissions on the command line, networking from the terminal, and other concepts that can change your CLI game. This is more a tour of important concepts than a UNIX command list, but I think that’s more valuable. Let’s get to it!

Dealing with User Permissions

User file permissions are one of the first very-foreign concepts many WordPress developers encounter. Rather than the simple act of creating a new PHP or CSS file, this is an extra level of complexity. It requires some understanding of how Unix thinks about user permissions.

The short version is that a computer has many different users, and those users have different rights to access and do different things. This is for security reasons: if you only let certain people do some inherently-dangerous operations, your whole system will be more robust in the face of threats.

sudo lets you become a more powerful user

The first, and most common kind of user permissions issue you will face getting comfortable with the CLI is that you’ll sometimes not be powerful enough to do something like delete the file you want. This often means that you’ll issue commands and your terminal will silently disobey you and instead do nothing.

To deal with this, there is a command that runs the command with elevated permissions: the “sudo command.” Some commands on your Mac or Linux system (again those are both examples of Unix systems) can only by done by the most powerful “root” user. To become the “root” user temporarily, you use the sudo command before your command. (Obligatory XKCD.) If you wanted to rm your /etc/hosts file (don’t!), you would make sure that happened by running the command as root. You’d do that with the command:

sudo rm /etc/hosts

Then, most likely, you’d be prompted for the “sudo password.” On a typical Mac, that means the password by which you access the account. For the Linux server, there is more often a separate “sudo” password. In either case, if that is successfully supplied the command will execute as a root user and be (virtually) guaranteed to succeed.

You can always do everything using sudo but it can get to be a lot of typing and a little annoying if you need to do a lot of commands as an elevated-permissions user. There is a command that many Unix systems provide for this kind of scenario: su. In short, the su command is how you become the super user for more than one command. Like with sudo you’ll be asked for your password. But unlike sudo, su will make it so you don’t have to type sudo on the next command.

chmod is how you change file permissions

Beyond individual commands that need elevated or different permissions, individual files will have set levels of permissions and different associated owners. This is less commonly needed than sudo, so we’ll go into a little less depth.

A file has different powers that a user can have with it. For a file, there are permissions granted to the creating (owning) user, permissions granted to the group that owner belongs to, and then permissions that every user has to that file. These are all general examples of Unix file permissions you might have.

The specific way those are standardized is a little complex. But it’s a fixed-octet system. You’ll often hear people talk about 777ing a file, which means giving everyone — user, group, and the world — the ability to read, write, and execute the file. This is the “nuclear option”, effectively the same as throwing around some !importants in CSS. So do it only as a quick fix on a development setup, or a very short-term last resort.

But to do it to all the files in a folder, you’d use the chmod command. chmod stands for “CHange MODe”. To 777 a folder, you’d run the command:

chmod -R 777 folder

chown is how you change file ownership

Like chmod, you use chown to change some of the ownership metadata of a file. Where chmod is for the permission levels granted to each class of users, chown changes the identity of the owning user. So you assign it from one to the other. I have used chown maybe a dozen times in my years as a web developer using the command line. So I always have to look up the syntax. Here’s a pretty good webpage explain its basic parameters.

Network Utilities For the CLI

As a web developer, a large part of what we do is interface with remote computers. That means that there’s a disproportionate importance to accessing and working with files from away from your computer. So this section can’t be missed.

ssh is how you connect to other servers

A powerful thing about the terminal is that the difference between using your own computer via a terminal and using a remote one via an SSH connection is hard to even notice.

We’ve touched on ssh a little bit in other posts, but it is the way that you connect to a remote Unix server and access its CLI. So if you don’t have physical access to a computer with a screen on it, you’ll almost always be connecting to it via the SSH command and then using it from your own terminal emulator. One of the great and powerful things about the terminal is that the difference between using your own computer via a terminal and using a remote one via an SSH connection is hard to even notice.

So how do you connect via SSH? Authorization is a topic that this article is already too long to cover in depth. But if you’ve already set up SSH keys and loaded them onto the remote server (if you’ve not, that linked GitHub guide is solid), all you’ll need to do so something like:

ssh user@domain.com
# or
ssh user@255.255.255.255

If password authentication is enabled, it may prompt you to enter that. If not, you’ll be logged in or rejected based on your SSH keys.

Use rsync and scp to move files to and from remote servers

If you have SSH set up, you’ll be able to use either the scp (secure copy) or rsync (remote sync) command to move files securely to and from your server. And I never do, but ftp and sftp are also simple command line applications that you can use from the CLI. SFTP — secure file transfer protocol — piggybacks on SSH the same way that rsync does, FTP does not.

All these commands are pretty similar and the differences between them are pretty subtle and not super important to negotiate in the context of this article. As such, we’ll just give you a single quick summary of moving data with rsync to move all files in a folder into a folder in a remote server, it would look something like:

rsync --progress -rz localfolder/* user@domain:/full/remote/path

This is just a basic rsync request, with to and from in that order, be we’ve got some interesting arguments and flags in it. --progress just makes rsync shows more data as it works than it does by default. -r makes the move recursive, in case there are folders inside our folder. -z makes compress the data for transmission. (For slow computers, -z is slower. For slow internet connections, -z is faster.)

curl & wget let you download content from the internet

To pull down files when you don’t have SSH authorization to a server, you will typically use the curl or wget commands. (Some cool kids swear by HTTPie). When would you do this? If you need to download a web page or specific large file from a remote server. Installing WP-CLI and lots of other command line software relies on it. And some people use then regularly for testing REST APIs. Given how long this article is and how deep these commands go, for now we’ll be happy that you know what these commands are for.

Concepts of the Command Line

Finally, there are various loose end grab-bag things you need to know how to do as a Unix command line user which don’t fit well into the other buckets of this article or the previous ones. These are things that are game-changers when understood, so please don’t stop reading!

$PATH is where you look for commands

As we’ve talked about, all commands you run in the terminal are just simple programs. As such, you’ll need that program located somewhere on your storage drive, and your terminal needs a way to find it. The very simple explanation of it is that your $PATH is a list of all the places that your terminal is configured to look for those commands.

This isn’t something you completely need to understand to make use of the terminal, but understanding that you can’t type wp in some terminals because it’s not in a place that is already in your $PATH, or that you’ve not added that place that it is to your $PATH is really useful.

Further depth is really beyond our scope here, but to see your current PATH on the terminal, just type the command

echo $PATH

And you’ll see a long string of colon-separated (:) locations on your hard drive. All the commands you use are just little files in one of those folders. Everything we’ve talked about from ftp to chown.

alias lets you rename common command structures

If you’ve used any kind of computer system for long, you’re probably familiar with the idea of shortcuts that let you do the same thing with less typing or clicking. On a Unix command line these sorts of shortcuts are called BASH aliases. They’re simple text-expansions that are not explicitly expanded as you look at your terminal, but do expand before the command executes.

So if you find yourself typing rsync --progress -rz ... a lot, you could instead give yourself the ability to type brsync ... if you created an alias. How? You can just type into your BASH command line something like:

alias c="clear"

Then, for the life of that terminal session, “c” and the return key would be enough to clear the output of that terminal screen. Four fewer keystrokes is at the edge of “not worth it!” for me. But for longer examples like rsync, it’s worth it.

BASH profile

The big disadvantage of alias as we explained declaring them above is that if you exit that terminal and make a new one, you will have to recreate all your aliases. Which kind of defeats the concept of them giving you speed and productivity improvement.

That’s where the idea of a .bashrc or .bashprofile comes into play. (If you’re using a different shell than BASH, these are likely to have different names…) This is a file of commands that are run by the shell at the start of loading up a session for you. So this is where people put their aliases. There are other things you’ll sometimes put in them, but that’s the most prominent.

I took a look at my personal .bashrc file, and the only thing I had in it were aliases. And a weird $PATH modification from ages ago that was now superfluous.

PHP Details

PHP from the command line is a complicated and diverse topic. The core thing I want to make sure you know, as a WordPress developer, is that you can run PHP from the command line. The specific PHP you get depends on your system, but you can execute PHP files from the command line. This is a big part of how tools like WP-CLI and Composer are in PHP.

I also want to note that you’ll sometimes encounter a strange file format called a “PHAR” as you get into using the command line as a PHP developer. A .phar file is just compressed PHP code, that the PHP engine can run without uncompressing. Speaking frankly, I don’t comprehend its exact nature. And don’t need to. What I do know is that both WP-CLI and Composer download as .phar files and I’m cool with that.

What We’ve Learned about Advanced Command Line Concepts

This article has not been exhaustive. There are corners of using BASH on Linux or a Mac that we’ve not covered. Which is to say nothing about how many of the topics we’ve glossed over and given a quick summary of. But I hope by reading this you’ve got an understanding of most of the aspects of how the command line works. And have somewhere to start as you get time for further study.

The Unix command line is one of the shibboleths that people use to distinguish web developers who have lots of experience from those that don’t. That’s because it’s not essential, but is a giant productivity booster. You don’t have to learn it, but should definitely think about it. Happy hacking!

Yay! 🎉 You made it to the end of the article!
David Hayes
Share:

3 Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments
Working With The Command Line and WP-CLI – WPShout
June 6, 2017 12:15 pm

[…] Mastering the Unix Terminal: Working With Permissions, Networking, and Other Key Concepts […]

The What, How and Why of WP-CLI: WordPress in Your Terminal | WPShout
January 31, 2017 10:28 am

[…] think or worry about WP-CLI. (But if you’re interested, here are the basics of file and non-file Unix CLI commands.) WP-CLI isn’t essential and it’s not something you should ever feel bad about. […]

L’hebdo de l’écosystème WordPress n°71 - WPHebdo
January 24, 2017 12:04 am

[…] Mastering the Unix Terminal: Working With Permissions, Networking, and Other Key Concepts – WPShout […]

Or start the conversation in our Facebook group for WordPress professionals. Find answers, share tips, and get help from other WordPress experts. Join now (it’s free)!

3
0
Would love your thoughts, please comment.x