Episode 2 Viewing files

We look at viewing files using commands like cat, more, less, head, and tail, including using those in short pipelines. We also try opening files in external applications using open or xdg-open (and live dangerously by dumping a binary file with cat).

4 August 2015

[Rhythmic, dark electronic intro music]


Hi, welcome back to Command Line TV. I’m Chris League, with me is my co-host Chris Lopes.

Last time we learned how to list files and navigate the directory structure.

And today we’ll cover the basics of viewing and manipulating files from the Unix terminal.

First are there any questions or issues you’d like to address from last time?


Actually I had one. I remember last time we navigated using cd,

We did that in two different ways.

We did it the relative way from the directory we were currently in,

And then we also did it using the tilde (~). Is there a big difference between those two?


Not really, it’s just a matter of what’s convenient, but

there is terminology about them. You said relative for one, which is correct.

So it’s relative if it matters where you’re starting from. And when you started with ~,

then it’s called an absolute path because then it doesn’t matter where you start from,

it always goes to your home directory first.

So one way to think of that is that an absolute path starts with a /

and the ~ is just really an abbreviation.

So I’m going to do here a command called echo ~ and this shows me that it’s actually

echo ~

an abbreviation for /home/cltv, which is my username. So that’s an absolute path.


So this terminal actually looks a little different as well.

I guess is that because we’re using Linux as opposed to the Mac this time?


Yeah, last time we were on a Mac terminal, and this is Linux.

There are some minor differences. One of them is that the ls output

actually has color in it.

The prompt also looks a little different, but it shows the same stuff.

It’s got your username and host name (the name of the machine), current directory –

so if I go to Downloads, then it shows up there. And then the dollar sign is my prompt.

And one cool thing about the colors is that it’s showing us directories in blue,

and it sometimes has other colors for other file types.

So that helps us distinguish things in a similar way to doing that ls -F

ls -F

that we learned last time, which adds a slash.

That’s a little redundant now because the color gives it away.


Can the ls command on a Mac also be configured to use colors?


Not directly, but you can install a different version of ls on the Mac if you want to.

So the version of ls I’m using here – you can do this double-dash option --version

ls --version

– it needs to be exactly like that, no extra spaces.

This shows me that I’m using the GNU version of ls,

which has this feature of adding colors.

And on the Mac you’re using the BSD version of ls

these are just two different variants of the Unix operating system.

And so you can install the GNU version on the Mac,

but it’s not the version that comes with it by default.

The other thing that GNU supports is a lot of commands have a double-dash --help option.

ls --help

So if we do ls --help, you see that it showed us tons of options here –

I have to scroll up to see the rest.

But this gives you a quick reference for the different options that it supports.

And we can find things that we learned last time, like reversing the order of the sort.

So we can see those details.


So the --help, does that work on all commands, or?


I would say it works on most commands, certainly all commands from the GNU project,

but not every command is from GNU.

But it’s always worth trying, because a lot of commands do support it.


In future episodes we also hope to address questions and comments from our viewers


Yeah I hope you’ll get in touch with us with your questions, corrections, comments,

and we’ll be happy to respond on the show. How will they get in touch with us?


Uh right now we have two options: on Twitter @commandlinetv

or via email heychris@commandline.tv.


Alright, thanks.

So now we’ll learn a little about viewing and manipulating files from the command line.

So I’m here in my Downloads folder.


So now that we learned how to navigate through the directories,

how can we actually view the files that are within those directories?


Right, so there’s a text file here about languages, and the most basic command

to dump out the contents of a file is called cat, which stands for catenate

it doesn’t matter, but that’s what it’s called.

So i can type cat and then the name of a file, languages.txt, and it will just

cat languages.txt

dump out the contents right onto my terminal, like that.

Now that was a really long file so I have to scroll up to see more of the content of it.

But another way so that I don’t have to scroll in my terminal is

I can replace cat with a command called more.

more languages.txt

And what more will do is just show me one screen-full of that file,

and it gives me this prompt at the bottom with a percentage of how much of the file I’ve seen.

And I’ve got a couple options here. If I just want to see the next full page,

I can hit the space bar. So now I’m looking at page 2, and so on.

It pages through the file that way.

And if I’m done looking I can hit the q to go back to my regular prompt.


Now does cat and more work on files other than text files, such as the .gz there?


Yeah, so gz is like a compressed file, which means it may not be viewable as plain text.

And I can try to do cat on that –

cat hello-2.10.tar.gz

2.10, okay –

but I’m going to regret it [laughs]. I’ll show you what it does anyway.

So if I do cat on the .gz file, I start to get a bunch of this stuff

dumped to my terminal. So it really is just dumping out the contents of that file,

but that’s not something that I can see on my terminal in a reasonable way.

So what I have to do here to fix this is hit control-C to stop it –

and sometimes that’ll take a moment. And once it actually stops,

what you might want to do is reset your terminal. There’s a command called reset


sometimes dumping the contents of a binary file will mess with your terminal settings

and things might not come out quite right.

Sometimes when you start to type after that, it will actually show you funny characters

instead of the keys you pressed. But typing reset should fix all of that.

Now my terminal is back to its default settings.


Now that we learned cat to open text files, and tried to open a binary file,

is it the same process to open images as well, and PDFs?


So images and PDFs you might want to be able to view from the command line,

but you can’t actually see the content directly.

However, you can open them in another program by typing a command.

So I’ve got here – down in some sub-directory – I’ve got some figures

that are part of a book. And a lot of these are in Postscript format,

which we’re not going to worry about right now.

But I do have down here an image file, in PNG format.

ls *.png

And if I want to open that on the command line, on Linux the command would be xdg-open.

What this does is it connects to your desktop environment that you have installed,

and chooses the appropriate viewer for the file type.

So you can use this for both images and PDFs, and some other things as well.

So I xdg-open gridworld.png and it opens in this external application

xdg-open gridworld.png

to show you the image. And then you can close that and switch back to the command line.

On a Mac, the command that does the same thing – that hooks into the graphical environment

on the Mac – it’s just called open. So you would say open gridworld.png

open gridworld.png

and that won’t work on Linux but it works fine on Mac.


And I noticed at the top you did ls asterisk – what is that?


Yeah, so this asterisk, or ‘star’ as I will usually say, is a wildcard.

It just matches anything. So this is a way of showing – so if I just do ls

it shows all the files in this directory. ls *.png means show me all the files

ls *.png

where there is anything followed by a .png. So any file that matches that.

And so you can use that in a nice way to limit what files you’re seeing,

to just the files that end with .fig

it doesn’t have to have a boundary with the dot, you can use it elsewhere.

Like I can show all files that have ren in the name.

So this *ren* means anything, followed by ren, followed by anything.

ls *ren*

And that ren matches the middle of the word reference, so it shows those filenames.

We’ll say a lot more about wildcards in another episode, but that’s a good introduction.


Now I see that after the ls you have the *ren*

earlier when we did ls we had a dash in front of it.

So is there a difference between those options and what we’re seeing right now?


Yeah, sort of…

the syntax of these commands is usually that you have the name of the command

(which is ls in this case), and a space, and then you typically put your options

if you have any. So -l for example to get the detailed listing,

and then space, and then you do any other arguments that you would have.

So for example, names of files or wildcard patterns for files, or whatever.

So I can do that to get a detailed listing of just those files that I selected before.

ls -l *ren*

Some commands also support putting the options after the arguments,

so you could do ls *ren* and then -l at the end.

ls *ren* -l

And for ls that ends up being the same thing. Not every command supports that though,

and it’s more typical to put the options before the arguments.

When you do --help for a command, it will often show you a brief synopsis

of how to use it, including the order that the options and arguments should go in.

We did ls --help previously, but I want to also introduce that we can keep it

from scrolling way off the page by using the more command, but in a different way.

So previously we said more and a filename, and now I’m using this ‘pipe’ character |

and it’s usually, on most keyboards it’s shift-backslash.

So we call it ‘pipe’ or ‘vertical bar’, but Unix people will just call it ‘pipe’.

What this means is take the output of the thing on the left

and feed it to the program on the right. So we’re combining two programs together

ls --help | more

and then we get the help message from ls but it’s paged so we see

the --More-- prompt at the bottom. And here’s that usage synopsis I was talking about,

where after ls you put the options and then you put the files you want to see.

And then more allows us to page through this just like we page through a text file,

or hit q to go back to the prompt.


I noticed that when you did ls|more that we could scroll down through the list,

but we couldn’t go back up.

What if I wanted to go back up to view the options I already passed?


Yeah, exactly, so more only allows you to go in one direction.

That’s a serious limitation to it, so a lot of people actually use a newer command

called less. So, you know, more and less are kind of –

less was named that to be the opposite of more or something like that?

So it’s just a silly name.

But it does essentially the same stuff. The prompt looks a little different,

ls --help | less

so it just has this colon : down here where my cursor is.

But it allows me to page forward in the same way using the space bar.

But I can also go back up, and I can do that with the arrow keys to go up a line at a time,

or you can use page-up and page-down to go up toward the top and down toward the bottom.

There are a couple other commands that it supports too.

If you want to go all the way to the top with one keystroke, that’s the less-than key.

So < takes me all the way to the top, and > all the way to the bottom.

And then just like more, you can use q to quit.

However on less you have to use q to quit. One thing about more is that

if you page all the way to the bottom, it just exits by itself when it gets to the bottom.

less doesn’t do that. Page all the way to the bottom,

it stays there still running until you hit q.

So it’s really a matter of preference which one you want to use,

but less has more features than more.


So if I didn’t want to view the entire file,

but I just want to know what’s at the beginning or end of it, do I have options for that?


Yeah, very good. There are two commands, one called head and one called tail,

that show the beginning and end of files.

tail is especially useful for doing log files.

So I’ve got a log file down here in this hello project.

There’s a config.log which keeps track of what happened when I tried

to configure this software. And if I just want to review the last couple of lines

of that file, to see if it was successful or there was an error.

You can see tail config.log and it will just dump out the last few lines –

tail config.log

looks like it’s 1, 2, 3, … 10 lines that it’s showing.

And the bottom-most line just says exit 0, which means it was successful.

You can configure tail in order to show you a different number of lines besides 10.

So if I only want to see that last one line,

I can say -1 and there’s the very last line from that file.

tail -1 config.log

So when we were talking about the syntax before


Yeah, that’s one of the options that tail supports.

So you put that, and then you put the filename afterwards.

How about head, same idea just shows you the top of the file.

So this can allow you to identify files, for example.

Like a lot of times there is authorship information or copyright information

at the top of the file. So I’ve got here a file called Changelog.

And the Changelog probably has information about what changes have been made

to this software. And generally when we keep those files,

we put the most recent stuff at the top.

So if I want to see the most recent stuff in the Changelog, I see here –

head ChangeLog

head just shows the top ten lines, and the first entry was from November 2014

and it’s for version 2.10.

So that’s an example of using head and again I can just get the top –

let’s say four lines of that file, using the -4 option.

head -4 ChangeLog

One other cool way to use head and tail is after a pipe –

the same way that I showed you to use more. Like we did ls --help|more, right?

Well instead of that we can pipe to head, and what do you think that’s going to do.


I’m assuming it will only show the first few lines for the help


Yeah, the first few lines of that help message, and then just return me to the terminal.

ls --help | head

So if all I really wanted to see was the synopsis at the top,

head is a great option for that.


Now could we do ls and --help and then

combine head with the amount of lines we want to show?


Yup, so ls takes its option of --help, the result of that can be piped into head,

and you put its option out here, so let’s say we want to see 3 lines.

ls --help | head -3

Then there’s just the 3-line synopsis.




So this is what I think is the really cool thing about the terminal.

You have these little commands that you can then mix and match

in a bunch of different ways to get things done.

And we’re only seeing the glimpse of that right now but we’re going to do

much more powerful pipelines with some other commands in future episodes.


Thanks for joining us today for episode 2. Professor, what’s the topic for next time?


So I think next time we’ll dig into wildcards a little bit more.

And we’re going to use pipes for simple text manipulation with a few more commands

we’ll learn. But we’ve already started to see the power of pipes to some extent,

just with commands like ls and head and tail and more and less.

We’re going to see even more sophisticated ways to combine small commands

together in the next episode.


Sounds good.


See you then!

[Dark electronic beat]

[Captions by Christopher League]