In the next instalment we’ll be moving on to look at the so-called Environment within a command shell, but before we do that we need to lay some ground work. Specifically, we need to learn how to read and edit text files from the command line.
In this instalment we’ll start with the most common commands for reading files, and then move on to look at the simplest of the command line editors. For those interested in learning a little more I’ll also give a very quick overview of one of the more powerful command line editors, but feel free to skip over that section if you like, future instalments won’t assume that knowledge.
Like with so many things in tech, it doesn’t matter if you don’t know everything, what matters is that you have the skills to quickly find the information you need when you needed it. Programmers don’t memorise entire APIs, they simply learn how to search them, and how to interpret the results of their searches.
This is an area where the Linux/Unix command line environment really shines. All Linux & Unix distributions, including OS X, have a built-in manual that allows you to quickly find the documentation you need, when you need it. Every command line command/program can add its documentation to the system manual. In fact, each command/program can actually add multiple documents to the manual. Tools that make use of configuration files will often add a separate document to describe the structure of the configuration file for example.
Every built-in command will have an entry in the manual, and any software you install via the standard package management tools for your distribution will almost certainly bundle the related manual entries as part of the package. This is also true on OS X, where package mangers like Mac Ports will also bundle manual pages with the software they install, and even stand-alone
.pkg installers for command line tools will usually also install manual entries. If you run it from the command line, the changes are very high that there will be a manual entry for it on Linux, Unix and OS X.
Last night I gave a talk to Astro2, the Astronomy & Physics society in NUI Maynooth. This is a slightly updated version of a talk I’ve been developing over the past few years. It’s an hour long an aims to explain the jargon you’re likely to come across on Astronomy websites (or magazines if you still do the dead-tree thing), to quickly summarise the kinds of things you can see in the sky, and to look at the kinds of equipment you might want (no, you really don’t need a telescope).
Note: This blog post formed the basis for the Chit Chat Across the Pond segment on Episode 441 of the Nosillacast Podcast.
It’s very hard to tell from a finish photograph what went into making it, so I thought it might be interesting to follow a single photo (below) all the way from idea to finished product. The photo is of the International Space Station passing in front of the Moon, and the lovely tower in the foreground is Tyrconnell Tower in Carton Estate in Ireland.
In the previous instalment we looked how Unix-like operating systems like Linux and Mac OS X represent processes. We then went on to look at the commands for listing running processes, and filtering and sorting them in various ways. This time we’ll move on to controlling processes, specifically, starting and stopping them.
For various reasons there’s been a bit of a gap between the previous instalment and this one. A big part of the reason is that I’d been putting off a lot of topics I wanted to talk about on Chit Chat Across the Pond until there was a logical break in this Terminal series. Having finished with the file system at the end of the part 7, I had my logical break point. Now it’s time to get stuck back in though, and start a whole new topic – processes.
We’ll start with a little history for context, then have a look at the model OS X uses to represent processes, and finish by looking at some commands for listing the currently running processes on your system.
Inspired by a recent episode of The Mac Cast I decided to see if I could come up with a simple way of getting a word count of a PDF on OS X using only tools that come standard with the OS.
Because of OS X’s Unix underpinnings, all Macs have access to the Unix
wc command which calculates word counts on given input. OS X also has a handy built in Terminal command to access the contents of the clipboard (
pbpaste). This leads to an obvious simple manual solution:
- Open the PDF in Preview
- Select All Text
- Copy to clipboard
- Run the Terminal command:
pbpaste | wc -w
This is a bit cumbersome though, so I went on to create a simple OS X Service to calculate the word count of any selectable text in any app (the fact that this is even possible, let alone easy, is why I love OS X).
For those of you just looking for a copy of the Service, you can download it here:
To install the service simply extract the automator file from the ZIP archive and copy it into either the
Library/Services folder in your home directory, or the system-wide service folder
Once the Service is installed you can use it in almost any OS X app (specifically in any app written using the standard Cocoa libraries) by selecting some text, right-clicking on it, and selecting the Word Count service:
When done the results will look something like this:
Those of you who want to see how easy this Service was to write, read on and I’ll walk you through it.
So far in this series we’ve focused mostly on the file system, looking at the details of file systems, how to navigate them, and at file permissions and metadata. We’re almost ready to move on and start looking at how processes work in Unix/Linux/OS X, but we have a few more file-related commands to look at before we do. In this instalment we’ll be looking at how to manipulate the file system, in other words, how to create files and folders, how to copy them, how to move them, how to rename them, and finally how to delete them.
In the previous instalment of this series we had a look at how standard Unix File Permissions worked. We looked at how to understand the permissions on existing files and folders, but not at how to change them. We also mentioned that the standard unix file permissions are now only a sub-set of the file permissions on OS X and Linux (OS X also supports file ACLs, and Linux has SELinux as an optional extra layer of security).
In this instalment we’ll start by biting the bullet and dive into how to alter standard Unix File permissions. This could well turn out to be the most difficult segment in this entire series, regardless of how big n gets, but it is very important, so if you have trouble with it, please don’t give up. After we do all that hard work we’ll end with a simpler topic, reading OS X file ACLs, and OS X extended file attributes. We’ll only be looking at how to read these attributes though, not how to alter them.
In this instalment it’s time to make a start on one of the most important Unix/Linux concepts, file permissions. This can get quite confusing, but it’s impossible to over-state the importance of understanding how to read and set permissions on files and folders. To keep things manageable, I’m splitting understanding and altering permissions into two separate instalments.
Linux and Unix (and hence OS X) all share a common file permissions system, but while they share the same common core, they do each add their own more advanced permissions systems on top of that common core. In this first instalment we’re only going to look at the common core, so everything in this instalment applies equally to Linux, Unix, and OS X. In future instalments we’ll take a brief look at the extra file information and permissions OS X associates with files, but we won’t be looking at the Linux side of things, where more granular permissions are provides through kernel extensions like SELinux.