Posted on Leave a comment

Command line quick tips: Using pipes to connect tools

One of the most powerful concepts of Linux is carried on from its predecessor, UNIX. Your Fedora system has a bunch of useful, single-purpose utilities available for all sorts of simple operations. Like building blocks, you can attach them in creative and complex ways. Pipes are key to this concept.

Before you hear about pipes, though, it’s helpful to know the basic concept of input and output. Many utilities in your Fedora system can operate against files. But they can often take input not stored on a disk. You can think of input flowing freely into a process such as a utility as its standard input (also sometimes called stdin).

Similarly, a tool or process can display information to the screen by default. This is often because its default output is connected to the terminal. You can think of the free-flowing output of a process as its standard output (or stdout — go figure!).

Examples of standard input and output

Often when you run a tool, it outputs to the terminal. Take for instance this simple sequence command using the seq tool:

$ seq 1 6
1
2
3
4
5
6

The output, which is simply to count integers up from 1 to 6, one number per line, comes to the screen. But you could also send it to a file using the > character. The shell interpreter uses this character to mean “redirect standard output to a file whose name follows.” So as you can guess, this command puts the output into a file called six.txt:

$ seq 1 6 > six.txt

Notice nothing comes to the screen. You’ve sent the ouptut into a file instead. If you run the command cat six.txt you can verify that.

You probably remember the simple use of the grep command from a previous article. You could ask grep to search for a pattern in a file by simply declaring the file name. But that’s simply a convenience feature in grep. Technically it’s built to take standard input, and search that.

The shell uses the < character similarly to mean “redirect standard input from a file whose name follows.” So you could just as well search for the number 4 in the file six.txt this way:

$ grep 4 < six.txt
4

Of course the output here is, by default, the content of any line with a match. So grep finds the digit 4 in the file and outputs that line to standard output.

Introducing pipes

Now imagine: what if you took the standard output of one tool, and instead of sending it to the terminal, you sent it into another tool’s standard input? This is the essence of the pipe.

Your shell uses the vertical bar character | to represent a pipe between two commands. You can find it on most keyboard above the backslash \ character. It’s used like this:

$ command1 | command2

For most simple utilities, you wouldn’t use an output filename option on command1, nor an input file option on command2. (You might use other options, though.) Instead of using files, you’re sending the output of command1 directly into command2. You can use as many pipes in a row as needed, creating complex pipelines of several commands in a row.

This (relatively useless) example combines the commands above:

$ seq 1 6 | grep 4
4

What happened here? The seq command outputs the integers 1 through 6, one line at a time. The grep command processes that output line by line, searching for a match on the digit 4, and outputs any matching line.

Here’s a slightly more useful example. Let’s say you want to find out if TCP port 22, the ssh port, is open on your system. You could find this out using the ss command* by looking through its copious output. Or you could figure out its filter language and use that. Or you could use pipes. For example, pipe it through grep looking for the ssh port label:

$ ss -tl | grep ssh
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* LISTEN 0 128 [::]:ssh [::]:*

* Those readers familiar with the venerable netstat command may note it is mostly obsolete, as stated in its man page.

That’s a lot easier than reading through many lines of output. And of course, you can combine redirectors and pipes, for instance:

$ ss -tl | grep ssh > ssh-listening.txt

This is barely scratching the surface of pipes. Let your imagination run wild. Have fun piping!


Posted on Leave a comment

Command line quick tips: More about permissions

A previous article covered some basics about file permissions on your Fedora system. This installment shows you additional ways to use permissions to manage file access and sharing. It also builds on the knowledge and examples in the previous article, so if you haven’t read that one, do check it out.

Symbolic and octal

In the previous article you saw how there are three distinct permission sets for a file. The user that owns the file has a set, members of the group that owns the file has a set, and then a final set is for everyone else. These permissions are expressed on screen in a long listing (ls -l) using symbolic mode.

Each set has r, w, and x entries for whether a particular user (owner, group member, or other) can read, write, or execute that file. But there’s another way to express these permissions: in octal mode.

You’re used to the decimal numbering system, which has ten distinct values (0 through 9). The octal system, on the other hand, has eight distinct values (0 through 7). In the case of permissions, octal is used as a shorthand to show the value of the r, w, and x fields. Think of each field as having a value:

  • r = 4
  • w = 2
  • x = 1

Now you can express any combination with a single octal value. For instance, read and write permission, but no execute permission, would have a value of 6. Read and execute permission only would have a value of 5. A file’s rwxr-xr-x symbolic permission has an octal value of 755.

You can use octal values to set file permissions with the chmod command similarly to symbolic values. The following two commands set the same permissions on a file:

chmod u=rw,g=r,o=r myfile1
chmod 644 myfile1

Special permission bits

There are several special permission bits also available on a file. These are called setuid (or suid), setgid (or sgid), and the sticky bit (or delete inhibit). Think of this as yet another set of octal values:

  • setuid = 4
  • setgid = 2
  • sticky = 1

The setuid bit is ignored unless the file is executable. If that’s the case, the file (presumably an app or a script) runs as if it were launched by the user who owns the file. A good example of setuid is the /bin/passwd utility, which allows a user to set or change passwords. This utility must be able to write to files no user should be allowed to change. Therefore it is carefully written, owned by the root user, and has a setuid bit so it can alter the password related files.

The setgid bit works similarly for executable files. The file will run with the permissions of the group that owns it. However, setgid also has an additional use for directories. If a file is created in a directory with setgid permission, the group owner for the file will be set to the group owner of the directory.

Finally, the sticky bit, while ignored for files, is useful for directories. The sticky bit set on a directory will prevent a user from deleting files in that directory owned by other users.

The way to set these bits with chmod in octal mode is to add a value prefix, such as 4755 to add setuid to an executable file. In symbolic mode, the u and g can be used to set or remove setuid and setgid, such as u+s,g+s. The sticky bit is set using o+t. (Other combinations, like o+s or u+t, are meaningless and ignored.)

Sharing and special permissions

Recall the example from the previous article concerning a finance team that needs to share files. As you can imagine, the special permission bits help to solve their problem even more effectively. The original solution simply made a directory the whole group could write to:

drwxrwx---. 2 root finance 4096 Jul 6 15:35 finance

One problem with this directory is that users dwayne and jill, who are both members of the finance group, can delete each other’s files. That’s not optimal for a shared space. It might be useful in some situations, but probably not when dealing with financial records!

Another problem is that files in this directory may not be truly shared, because they will be owned by the default groups of dwayne and jill — most likely the user private groups also named dwayne and jill.

A better way to solve this is to set both setgid and the sticky bit on the folder. This will do two things — cause files created in the folder to be owned by the finance group automatically, and prevent dwayne and jill from deleting each other’s files. Either of these commands will work:

sudo chmod 3770 finance
sudo chmod u+rwx,g+rwxs,o+t finance

The long listing for the file now shows the new special permissions applied. The sticky bit appears as T and not t because the folder is not searchable for users outside the finance group.

drwxrws--T. 2 root finance 4096 Jul 6 15:35 finance