Command Line & Networking Primer

Command Line

What is the Command Line?

Everything in a Unix computer is a file. Every program it runs, every little toolbar, every document you own, and every little nuance about the way it runs, is a file. The command line, simply put, is a place where you can navigate through that file system and read/run those files. Within it, you type commands instead of clicking on buttons in a GUI. The command line can be very powerful, complex, and dangerous, but should be lauded and admired, not feared.

In general, these tutorials will take place on a Mac, because of their ease-of-use and unix-like filesystem. Following along with Linux will be very similar, but Windows might cause some problems (use at your own risk).

Mac users — Open the Terminal using Spotlight, or by going into your /Applications/Utilities folder.

Syntax

A command has three parts: the utility, the flags, and the arguments. The utility is required, and always comes first. The flags are usually optional, and can take both long (--flag) and short (-f) forms. The arguments are usually the last part of the command, and are generally required.

Try running this:

ls -l ~/Documents

In the above example, ls is the utility. It runs a program that lists directory contents. The -l is an optional flag that tells ls to display all the file list in long format. ~/Documents is the argument; it tells ls to list the directory contents at Users/<username>/Desktop (or equivalent on your OS).

You can learn how to use any command by typing man in front of it (man — for manual — is the utility, and the command you want to learn about is the argument. You can move up and down the documentation with your arrow keys, and exit by typing q. Often, but not always, you can also learn about a program by using the flag --help with no arguments, or even just by using the utility with no flags or arguments.

File systems

Every file on your computer is stored in a folder that is part of a larger tree. Let’s look at the following location:

/Users/<username>/Documents/helloWorld.txt

Replace <username> with your login’s username.

The first / is the root of that tree. It is where every file and folder on the computer is stored. Go ahead and see for yourself by typing the command cd / to change your directory to the root /, and see what’s there by using ls.

The next part, Users/, is a folder within /. Go ahead and cd into it.

On my computer, <username>/ is a folder within /Users, and Documents/ is a folder within <username>/.

Finally, a text file called helloWorld.txt is within my Documents/ folder.

You can cd back up a level by doing cd ../, and can go up multiple levels by chaining those ../s. Finally, the shortcut for /Users/<username>/ is ~/ — remember that; ~ (tilde) is your home (directory).

Basic Utilities

Below is a list of basic utilities that most people use regularly. Anything in caps with a $ in front of it is a variable that should be replaced with your specific needs.

man $UTIL displays the manual for the $UTIL.

ls $DIRlists the contents of the $DIR directory.

cd $DIRchanges directories to $DIR.

pwdprints the location of the current (working) directory.

cat $FILE prints the contents of the $FILE to the terminal.

cp $FILE $LOCATIONcopies $FILE to $LOCATION.

mv $FILE $LOCATIONmoves $FILE to $LOCATION.

rm $FILEremoves the $FILE (deletes it).

$CMD1 | $CMD2pipes (|) the output of $CMD1 into the argument of #CMD2.

sudo $CMD runs the $CMD as the super user (super user do).

sudo can be dangerous, so only use it if you know what the command you’re elevating is going to do. You can delete the entirety of your computer’s hard drive by running sudo rm -rf at the root directory (WARNING: DO NOT DO THAT!!).

Package Managers

A Package Manager is a tool that facilitates the download, installation, configuring, updating, and removal of utilities. While you can live without using a package manager (most utilities have instructions on how to install them manually), you’ll be much better off using one.

On Mac, please download Homebrew by running the following command in your Terminal (Bonus Question: can you tell me what this command is doing?):

Let’s take a moment to make sure all of our package managers are up to date and installed.

On a Mac, run brew update && brew upgrade to update the manager’s package list and upgrade anything that needs to be upgraded. Run brew doctor to make sure everything is working well.

Mac users should also run brew tap caskroom/cask to install Homebrew Cask; it’s an extension to Brew that allows you to download and install Desktop apps in addition to command line utilities.

Exercise 1 — Rainbows

Install the utility figlet and lolcat with your package manager

FIGlet your name, centered, in a non-default font (font examples can be found here, and can be used like this: -f mini)

Redo the command, but pipe it to lolcat (do this by combining the two commands with |)

The Network

The OSI model.

The layers of our common networking system are dense, complicated and not worth digging into at this time.

Addressing

IP Address

Each connected computer or microcontroller in a given network is considered a “device” or “host“. Each device in a given network will have an IP address. The IP address can be assigned by the device itself (setting a Static IP) or the address can be given to the device by a router using a process called DHCP. DHCP is most common in large wifi networks and is probably what your laptop is using now. We call this “dynamic.”

When communicating with an application on a different computer, you’ll need to know that computer’s IP address. If both computers are on the same network (same router or same large institutional network like CMU), connecting shouldn’t be a problem.

Networks almost always regulate how their devices access the internet. This means that directly communicating with a device outside of your immediate network can be tricky.

For most applications in this class, you’ll be working with devices on the same router. To make sure you have a clear communication path between devices, check the IP address on each. You can check this by typing ifconfig in the command line. Look for an inet address that is not 127.0.0.1 (which is your ‘localhost’ address, used for talking to other applications on the same device). The inet address may have an adddress such as 10.0.0.104 or 192.168.1.56. Communication shouldn’t be a problem if both devices are on the same subnet, which means the first 4 numbers of the IP address. Keep in mind, this only holds true if both devices are on the same network; so if Kim is in Indiana and his router gives him an IP of 192.168.1.56 and Pat is in Oregon and her router gives her an IP of 192.168.1.26, that doesn’t mean they can communicate, since their routers are on different networks (assuming no VPN, etc).

Ports

If you imagine that and IP address is like a device’s street address, the Port is like a given application’s apartment number within the device. When setting up a networking path on two applications, the listening application will need to declare which port it is listening to. This is usually a 4 or 5 digit number 12345 or 5555, etc. The sending application will also need to declare, along with the IP address, which port in the destination device its packets are intended to reach.

Port numbers less than 1000 are generally reserved and should not be used in your application. You should be aware of some specific ports, like 80 (which is the default port for HTTP) and 22 (which is reserved for SSH).

Protocols

UDP

User Datagram Protocol is a “transport level” protocol we often use for streaming continuous data. UDP is low latency and it does not require that the sender of UDP receive confirmation of receipt from the receiver. This means that UDP messages can get lost and nobody will know. We use UDP for streaming continuous information (people tracking, continuous sensor data, etc) because we want to get that information as soon as possible and we don’t care if packets are lost along the way because another packet will be coming right behind it.

OSC

Open Sound Control is an “application level” protocol that sits on top of UDP and allows users to send formatted, human-readable messages. An example of an OSC message may be /sensors/A/value 54.2145 or /heartbeat "I'm alive" 20170206 0.15. We often use OSC to stream sensor data between applications, as it is easier to read and route than plain UDP. OSC does have some overhead, so if you need to send a ton of data and bandwidth is an issue, you may want to develop a protocol based on straight UDP.

TCP

Transmission Control Protocol is the “transport level” protocol on which HTTP runs. TCP is slower than UDP because it requires a confirmation of receipt for each message. We use TCP for sending information that MUST reach its destination. For example if we want to send updates from our FitBit to a server every 10 minutes, we would use a protocol based on TCP because if one of those FitBit update packets didn’t arrive, our system might fail. We usually do not use TCP for streaming continuous data.