- I neglected to mention back in December that LinuxCommand.org reached the 3 million visitors mark. Thanks everyone!
- The book has been downloaded over 4000 times so far. That comes to about 100 downloads a day. That's pretty good, but I think it could do better. If you have enjoyed the book, why not help support the effort to train new Linux users? Mention the book on blogs and forums, post a review somewhere, announce its availability on news sites, and just generally talk it up. Let's all help make the world a more Linux-friendly place! For those of you who already have, thank you!
Friday, January 29, 2010
Some Site News
Wednesday, January 27, 2010
Project: Building An All-Text Linux Workstation - Part 8
After a long hiatus, we resume work on our all-text workstation. There are two reasons I waited so long to resume this series: 1. I wanted to devote my full efforts to finishing the book, and 2. I knew this next installment would be hard to write.
The topic for the next two installments is one that should be fairly simple -- email. Only it's not simple. In fact, it's rather hellish.
Our Debian system already has a working email system installed and running on it. In its default form, it allows the users of the machine to send email messages to each other. This is a traditional Unix idea, since all Unix-like systems (such as Linux) are intrinsically multi-user.
While our small workstation might not seem like a good candidate for such a configuration, it is actually quite useful. The reason being that you can send email from scripts and other programs. This is good for programs that run automatically and need to report problems to an operator. They can just send email.
Before we demonstrate this capability, I need to explain (a little) how email works.
Email systems consist of two (and sometimes three) different components. The most familiar component is called the Mail User Agent (MUA). This is a program like Evolution or Thunderbird that is used to read and compose email messages.
The real work of an email system however is performed by another component called a Mail Transport Agent (MTA) which is tasked with moving the email message from one machine to the next and delivering incoming messages into the addressee's mailbox for reading by the MUA. On some systems a third component, called a Mail Delivery Agent is used by the MTA to perform operations on received email messages before they are delivered to the user's mailbox. These operations can include things as sorting messages into mail folders and spam filtering.
Our Debian system has an MTA program called exim4 and several MUAs. The most sophisticated of the default MUAs is a program called mutt.
Let's fire up mutt and send ourselves some email:
me@linuxbox:~$ mutt
As mutt starts up, it prompts you to create a directory called Mail in your home directory:
/home/me/Mail does not exist. Create it? ([yes]/no):
Press the Enter key to select the default (yes).
Next we will see the mutt screen:
The mutt screen has a menu along the top, a message list in the middle, and a status line at the bottom. We also see an error message at the very bottom of the screen because we don't yet have a mailbox file. More about that in a minute.
Next, we compose a new mail message. We do this by pressing the m key. At the very bottom of the screen we are prompted for the address of the recipient. Since we are sending it to ourselves, we enter "me".
Next, we are prompted for a message subject. Let's enter "Test Message" at the prompt. mutt then brings up the nano text editor so we can compose our message:
We'll type in our message and then type Ctrl-o then Enter to save our message and then Ctrl-x to exit nano.
mutt then displays a summary of the message:
(Ignore the "twin7" in the hostname. It's an artifact of my network configuration.)
Again, we have a menu at the top of the screen. We use the "y" selection to actually send the message, so go ahead and type y.
mutt passes the message to exim4 for delivery. Type "q" to exit mutt. When the shell prompt returns, we should see a message like this:
You have mail in /var/mail/me
The shell periodically checks for updates to a mailbox file. The name of this file is stored in the environment variable MAIL and the interval for the update check is set by the shell variable MAILCHECK.
We can easily examine the contents of these variables like this:
me@linuxbox:~$ set | grep MAIL
MAIL=/var/mail/me
MAILCHECK=60
So we see that our mailbox is a file named /var/mail/me and that the shell checks for updates every 60 seconds.
Since email is always plain text we can look into our mailbox to see what email really looks like:
me@linuxbox:~$ less /var/mail/me
The contents of the mailbox will be something like this:
From me@linuxbox.localdomain Wed Jan 27 11:03:04 2010
Return-path:
Envelope-to: me@linuxbox.localdomain
Delivery-date: Wed, 27 Jan 2010 11:03:04 -0500
Received: from me by linuxbox.localdomain with local (Exim 4.69)
(envelope-from)
id 1NaAMC-0000fi-FF
for me@linuxbox.localdomain; Wed, 27 Jan 2010 11:03:04 -0500
Date: Wed, 27 Jan 2010 11:03:04 -0500
From: Linux User
To: Linux User
Subject: Test Message
Message-ID: <20100127160304.GA2578@linuxbox.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
This is a test message.
As we can see, the message is mostly header followed by the actual message content.
If we launch mutt again, the message will show up in the message list pane of its main screen:
me@linuxbox:~$ mutt
Pressing the Enter key will display the contents of the message.
Pressing either i or q will return you to the message list and q will exit mutt.
mutt is not the only MUA installed by default. There are some other programs that you can use on the command line to send mail. mail is one such program. The mail program is actually a full MUA like mutt but much older. You can think of it as mutt's stone-age cousin. It's rarely used as interactive mail reader but it finds a lot of use as command line email sender. It can accept standard input on the command line to create messages. Here's an example using mail to send the results of a command to a user:
me@linuxbox:~$ ls -l /usr/bin | mail -s "Listing of /usr/bin" me
This command sends the results of ls to user me. Using the -s option sets the message subject line.
Running mutt again proves that we now have a second message in our mailbox:
That's all for now. In the next episode, we'll look at how to deal with email from the outside world.
Further Reading
Here are some Wikipedia articles that provide some background and additional details:
Other installments in this series: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
The topic for the next two installments is one that should be fairly simple -- email. Only it's not simple. In fact, it's rather hellish.
Our Debian system already has a working email system installed and running on it. In its default form, it allows the users of the machine to send email messages to each other. This is a traditional Unix idea, since all Unix-like systems (such as Linux) are intrinsically multi-user.
While our small workstation might not seem like a good candidate for such a configuration, it is actually quite useful. The reason being that you can send email from scripts and other programs. This is good for programs that run automatically and need to report problems to an operator. They can just send email.
Before we demonstrate this capability, I need to explain (a little) how email works.
Email systems consist of two (and sometimes three) different components. The most familiar component is called the Mail User Agent (MUA). This is a program like Evolution or Thunderbird that is used to read and compose email messages.
The real work of an email system however is performed by another component called a Mail Transport Agent (MTA) which is tasked with moving the email message from one machine to the next and delivering incoming messages into the addressee's mailbox for reading by the MUA. On some systems a third component, called a Mail Delivery Agent is used by the MTA to perform operations on received email messages before they are delivered to the user's mailbox. These operations can include things as sorting messages into mail folders and spam filtering.
Our Debian system has an MTA program called exim4 and several MUAs. The most sophisticated of the default MUAs is a program called mutt.
Let's fire up mutt and send ourselves some email:
me@linuxbox:~$ mutt
As mutt starts up, it prompts you to create a directory called Mail in your home directory:
/home/me/Mail does not exist. Create it? ([yes]/no):
Press the Enter key to select the default (yes).
Next we will see the mutt screen:
The mutt screen has a menu along the top, a message list in the middle, and a status line at the bottom. We also see an error message at the very bottom of the screen because we don't yet have a mailbox file. More about that in a minute.
Next, we compose a new mail message. We do this by pressing the m key. At the very bottom of the screen we are prompted for the address of the recipient. Since we are sending it to ourselves, we enter "me".
Next, we are prompted for a message subject. Let's enter "Test Message" at the prompt. mutt then brings up the nano text editor so we can compose our message:
We'll type in our message and then type Ctrl-o then Enter to save our message and then Ctrl-x to exit nano.
mutt then displays a summary of the message:
(Ignore the "twin7" in the hostname. It's an artifact of my network configuration.)
Again, we have a menu at the top of the screen. We use the "y" selection to actually send the message, so go ahead and type y.
mutt passes the message to exim4 for delivery. Type "q" to exit mutt. When the shell prompt returns, we should see a message like this:
You have mail in /var/mail/me
The shell periodically checks for updates to a mailbox file. The name of this file is stored in the environment variable MAIL and the interval for the update check is set by the shell variable MAILCHECK.
We can easily examine the contents of these variables like this:
me@linuxbox:~$ set | grep MAIL
MAIL=/var/mail/me
MAILCHECK=60
So we see that our mailbox is a file named /var/mail/me and that the shell checks for updates every 60 seconds.
Since email is always plain text we can look into our mailbox to see what email really looks like:
me@linuxbox:~$ less /var/mail/me
The contents of the mailbox will be something like this:
From me@linuxbox.localdomain Wed Jan 27 11:03:04 2010
Return-path:
Envelope-to: me@linuxbox.localdomain
Delivery-date: Wed, 27 Jan 2010 11:03:04 -0500
Received: from me by linuxbox.localdomain with local (Exim 4.69)
(envelope-from
id 1NaAMC-0000fi-FF
for me@linuxbox.localdomain; Wed, 27 Jan 2010 11:03:04 -0500
Date: Wed, 27 Jan 2010 11:03:04 -0500
From: Linux User
To: Linux User
Subject: Test Message
Message-ID: <20100127160304.GA2578@linuxbox.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
This is a test message.
As we can see, the message is mostly header followed by the actual message content.
If we launch mutt again, the message will show up in the message list pane of its main screen:
me@linuxbox:~$ mutt
Pressing the Enter key will display the contents of the message.
Pressing either i or q will return you to the message list and q will exit mutt.
mutt is not the only MUA installed by default. There are some other programs that you can use on the command line to send mail. mail is one such program. The mail program is actually a full MUA like mutt but much older. You can think of it as mutt's stone-age cousin. It's rarely used as interactive mail reader but it finds a lot of use as command line email sender. It can accept standard input on the command line to create messages. Here's an example using mail to send the results of a command to a user:
me@linuxbox:~$ ls -l /usr/bin | mail -s "Listing of /usr/bin" me
This command sends the results of ls to user me. Using the -s option sets the message subject line.
Running mutt again proves that we now have a second message in our mailbox:
That's all for now. In the next episode, we'll look at how to deal with email from the outside world.
Further Reading
Here are some Wikipedia articles that provide some background and additional details:
- http://en.wikipedia.org/wiki/Email
- http://en.wikipedia.org/wiki/Mail_transfer_agent
- http://en.wikipedia.org/wiki/Mail_user_agent
- http://en.wikipedia.org/wiki/Mutt_(e-mail_client)
- http://en.wikipedia.org/wiki/Mail_(Unix)
Other installments in this series: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Friday, January 22, 2010
.bashrc vs. .bash_profile
One continuing source of confusion among bash users is the question "Where should start-up settings go?"
As you may recall, bash reads startup files when it starts. These startup files are used to establish the user's environment including environment variables like PATH, command aliases, and programs to launch when the user logs in.
Shell sessions can be divided into two different types: login shells and non-login shells. bash uses different startup files for each type.
A login shell occurs when the user is prompted for a user name and password. Examples include virtual consoles (accessed by pressing Ctrl-Alt-F1 through Ctrl-Alt-F6) and terminal sessions on remote hosts using ssh or telnet.
A non-login shell is typically a terminal session launched on the graphical desktop.
Startup files can also be divided into two groups: global and personal. Global startup files are located in the /etc directory and apply to all users while personal startup files are located in each user's home directory.
So let's look at which files are read for each type of shell session:
Non-Login Shells
bash reads and executes the global startup file /etc/bash.bashrc followed by the personal file ~/.bashrc if they exist.
Login Shells
bash reads and executes the global startup file /etc/profile if it exists. Next, it attempts to read and execute ~/.bash_profile, ~/.bash_login, and ~/.profile in that order, stopping after the first file is found. Red Hat distributions by default supply ~/.bash_profile, while Debian distributions (such as Ubuntu) use ~/.profile.
Adding Your Own Settings
If you study the contents of either ~/.bash_profile or ~/.profile, you will see that both files source (i.e., read in the contents of) the ~/.bashrc file. This means that ~/.bashrc is read during the startup of both login and non-login shells, so putting your changes in ~/.bashrc is usually a safe bet.
Further Reading
The Linux Command Line covers this in Chapter 12.
The INVOCATION section of the bash man page contains a full description of the the bash startup process.
As you may recall, bash reads startup files when it starts. These startup files are used to establish the user's environment including environment variables like PATH, command aliases, and programs to launch when the user logs in.
Shell sessions can be divided into two different types: login shells and non-login shells. bash uses different startup files for each type.
A login shell occurs when the user is prompted for a user name and password. Examples include virtual consoles (accessed by pressing Ctrl-Alt-F1 through Ctrl-Alt-F6) and terminal sessions on remote hosts using ssh or telnet.
A non-login shell is typically a terminal session launched on the graphical desktop.
Startup files can also be divided into two groups: global and personal. Global startup files are located in the /etc directory and apply to all users while personal startup files are located in each user's home directory.
So let's look at which files are read for each type of shell session:
Non-Login Shells
bash reads and executes the global startup file /etc/bash.bashrc followed by the personal file ~/.bashrc if they exist.
Login Shells
bash reads and executes the global startup file /etc/profile if it exists. Next, it attempts to read and execute ~/.bash_profile, ~/.bash_login, and ~/.profile in that order, stopping after the first file is found. Red Hat distributions by default supply ~/.bash_profile, while Debian distributions (such as Ubuntu) use ~/.profile.
Adding Your Own Settings
If you study the contents of either ~/.bash_profile or ~/.profile, you will see that both files source (i.e., read in the contents of) the ~/.bashrc file. This means that ~/.bashrc is read during the startup of both login and non-login shells, so putting your changes in ~/.bashrc is usually a safe bet.
Further Reading
The Linux Command Line covers this in Chapter 12.
The INVOCATION section of the bash man page contains a full description of the the bash startup process.
Wednesday, January 20, 2010
In Praise Of Panix
During the editing of my book, one of my reviewers suggested that it would be cool if there could be an on-line shell host that readers could use to play with command line stuff while reading the book. While this is an interesting idea, it's not really practical for me to do.
If you have ever received an email from me, you know that my email address contains the domain "panix.com." What is Panix? Therein lies a tale.
Panix (short for Public Access Network Corp.) is a small, regional ISP located in New York City. According to Wikipedia, it is also the third oldest ISP in the world. They do the usual ISP stuff plus something special. They provide shell accounts. In fact, one of their slogans is "Your $HOME Away From Home." Here is a quote from their web site:
I'm not sure when I started using Panix, probably around 1996 and they have been my faithful partner ever since. Now since I don't live in NYC, I don't use Panix for my Internet connectivity. I'm a Verizon FiOS customer at present, but you can still use Panix even if they are not your "primary" ISP.
Panix offers an account called a "No-dial: Full Shell, Remote Login Only" which allows you to use SSH to reach your Panix shell account. From there you can access a huge array of command line programs and tools. Included with the account is web hosting, email (accessible directly from the shell with a text mail reader, or remotely via POP or IMAP), USENET access, and 500 MB of disk storage.
In addition to the services, there is the Panix community. Panix maintains their own hierarchy of USENET newsgroups for access within the Panix system. Here you will find a vibrant collection of Unix people and other colorful characters. There is also frequent interaction with the system administrators who are very experienced and knowledgeable. You can learn a lot just hanging around.
The No-dial account costs $10/month or $100/year if you prepay.
So if you want to experience what a large, multi-user Unix system (they run NetBSD) is like, give them a look
If you have ever received an email from me, you know that my email address contains the domain "panix.com." What is Panix? Therein lies a tale.
Panix (short for Public Access Network Corp.) is a small, regional ISP located in New York City. According to Wikipedia, it is also the third oldest ISP in the world. They do the usual ISP stuff plus something special. They provide shell accounts. In fact, one of their slogans is "Your $HOME Away From Home." Here is a quote from their web site:
Panix has been providing shell accounts and Internet connections since 1989 —nearly twenty years! During that time we've developed a reputation for technical know-how, reliability and customer service unmatched by today's Internet "superstores". If you're looking for access to a professionally-maintained UNIX host, with the latest versions of all your favorite newsreaders, mailers, compilers and internet clients —and if you want your home and email address to be good for the rest of your life, not just until some DotCom.CEO decides that shell services aren't profitable enough to keep running— you want a Panix account.
We are all shell users ourselves, and we are shell snobs. We know a well-maintained UNIX shell is indispensable for serious programmers, web developers and net fiends. Nothing else gives you as much control over your operating environment, nothing else is as flexible. You know that, we know that, and that is why Panix will always make shell access our first service.
I'm not sure when I started using Panix, probably around 1996 and they have been my faithful partner ever since. Now since I don't live in NYC, I don't use Panix for my Internet connectivity. I'm a Verizon FiOS customer at present, but you can still use Panix even if they are not your "primary" ISP.
Panix offers an account called a "No-dial: Full Shell, Remote Login Only" which allows you to use SSH to reach your Panix shell account. From there you can access a huge array of command line programs and tools. Included with the account is web hosting, email (accessible directly from the shell with a text mail reader, or remotely via POP or IMAP), USENET access, and 500 MB of disk storage.
In addition to the services, there is the Panix community. Panix maintains their own hierarchy of USENET newsgroups for access within the Panix system. Here you will find a vibrant collection of Unix people and other colorful characters. There is also frequent interaction with the system administrators who are very experienced and knowledgeable. You can learn a lot just hanging around.
The No-dial account costs $10/month or $100/year if you prepay.
So if you want to experience what a large, multi-user Unix system (they run NetBSD) is like, give them a look