linuxcommand-announce

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Site News: LinuxCommand.org Turns 10!

[William S. <bs...@pa...>]

LinuxCommand.org is 10 years old! The site first went live in March
2000. Since then I've had about 3.2 million visitors (at least
according to the statistics at SourceForge where I'm hosted), received
many kind emails from my readers, written a book, distributed a lot of
scripts, and been mirrored all around the world.

In the coming year, I hope to update the tutorials on the site. Much of
the text, believe it or not, dates back to the beginning of the site,
another testament to the enduring value of learning the command line.
But even so, the tutorials are getting a little outdated and my own
knowledge has grown considerably over the last ten years as well.

As you may have noticed, this blog has been pretty busy and I have
settled into a routine of posting twice a week (on Tuesdays and
Thursdays) and I have many more topics in mind to cover. And there is
always the book to improve. I've even toyed with writing another one...

Anyway, I want to thank everyone for their kind words of encouragement
and support. I know I don't always respond to each email that I
receive, but I do try. Speaking of support, you can support the work
here at LinuxCommand.org by purchasing your very own printed copy of my
book. I've donated money to a number of free and open source software
projects over the years and continue to "pay for my software" by
producing this site and performing software testing on projects that
interest me.

Thanks to everyone for ten great years!

Further Reading

A look at LinuxCommand.org over the years, courtesy of the Wayback
Machine:

- http://web.archive.org/web/*/http://linuxcommand.orgThe traffic
history of LinuxCommand.org:

-
http://sourceforge.net/project/stats/detail.php?group_id=3268&ugn=linuxcommand&type=sfweb&mode=alltime




--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/30/2010 06:00:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] byobu

[William S. <bs...@pa...>]

One of the features I have discovered during my testing of the
Ubuntu10.04 beta is a nifty program called byobu, a slick wrapper for
the screen terminal multiplexing program. If you are unfamiliar with
screen, please see the final installment of my Building An All-Text
Linux Workstation series.

byobu was introduced in Ubuntu 09.10 and continues in 10.04. The
name "byobu" comes from a Japanese word meaning "folding screen."
Essentially, byobu adds an improved user interface to screen and takes
advantage some advanced features in recent screen versions. On a system
so equipped, you launch byobu like this:

bshotts@twin7:~$ byobu

and you get a display like this:



We get a screen terminal session with system status notifications at
the bottom of the terminal display.

byobu allows the use of function keys in addition to the usual Ctrl-a
sequences supported by screen. As indicated at the bottom right corner
of the terminal, the F9 key invokes a menu:



Function Key Assignments

byobu assigns function keys to perform many of the common operations
performed by screen, such as opening new terminal sessions, moving from
session to session, and entering scroll back mode. Selecting the "Help"
item on the menu displays a map of the program's function key
assignments:



Status Notifications

Also of interest is the list of available system indicators which is
visible when the "Toggle status notifications" item is selected on the
menu:


As you can see this is a pretty big list.

Other Features

It's also possible to create default windows, that is, terminal
sessions that appear automatically when you start byobu. This is handy
if you have several applications that you want to start when you log in
at the terminal.

Further Reading


- The screen and byobu man pages
byobu's home at Launchpad

- https://launchpad.net/byobu
A Wikipedia article on Japanese folding screens

- http://en.wikipedia.org/wiki/By%C5%8Dbu





--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/25/2010 03:49:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Getting Ready For Ubuntu 10...

[William S. <bs...@pa...>]

Now that Ubuntu 10.04 Beta 1 has been released, it's time to start our
work. In this installment we will obtain a copy of Beta 1, make some
installation media, install it, and begin our testing.

Getting The Beta 1 Image

This page has links to the ISO images that we will use. Of course, you
could just download them from your web browser, but what's the fun in
that? Since we are command line junkies here at LinuxCommand.org, we
use the command line to download our images. You can do it like this:

me@linuxbox: ~$ wget url

where url is the web address of the ISO image we want to download In my
case, I used this command to get the "PC (Intel x86) Desktop CD":

wget
http://releases.ubuntu.com/10.04/ubuntu-10.04-beta1-desktop-i386.iso


Creating Installation Media

The next step is making the installation media. I always use
re-writable media for this kind of work, so we have to first "blank"
our CD, then write the image on it. To do this, we use the wodim
program. First, we need to determine what our system calls the CD
burner. We can do this with the following command:

me@linuxbox: ~$ wodim --devices

wodim will execute and print a list of the optical media drives it
sees. The results will look like this:

wodim: Overview of accessible drives (1 found) :
-------------------------------------------------------------------------
0 dev='/dev/scd0' rwrw-- : 'Optiarc' 'DVD+-RW AD-7200S'
-------------------------------------------------------------------------

On my system, we see that the CD-ROM drive/burner is the
device "/dev/scd0". Yours may be different.

insert the re-writable disk into the drive. If your system
automatically mounts the disk, unmount it with a command such as this:

me@linuxbox: ~$ sudo umount /dev/scd0

Next, we blank the media with this command:

me@linuxbox: ~$ wodim -vv dev=/dev/scd0 blank=all

The blanking operation will take several minutes. After it completes,
we can write the image with this command:

me@linuxbox: ~$ wodim -v dev=/dev/scd0 -data
ubuntu-10.04-beta1-desktop-i386.iso

After the write is completed, we need to verify that the disk matches
the ISO file. Using this command will do the trick:

me@linuxbox: ~$ md5sum ubuntu-10.04-beta1-desktop-i386.iso /dev/scd0
7ddbfbcfcc562bae2e160695ec820e39 ubuntu-10.04-beta1-desktop-i386.iso
7ddbfbcfcc562bae2e160695ec820e39 /dev/scd0

If the two checksums match, we have a good burn.

Installation

Depending on which variety of 10.04 you have downloaded (desktop,
alternate, etc.), the installation procedure should be familiar to any
Ubuntu user. The live desktop version differs from previous versions in
that it no longer prompts you for running live or installing
immediately after booting, rather you are forced to wait (and wait...)
for the entire live CD to come up before being prompted with a
graphical screen. Not an improvement, in my opinion.

After installation, the first thing we do is open a terminal and
perform an update to the system using the following commands:

sudo apt-get update
sudo apt-get upgrade

Be aware that during the testing period, the Ubuntu team releases a
steady stream of updates. It is not unusual for a hundred or more
package updates to be released each day during periods of heavy
development. I actually created this alias and put it in my .bashrc
file on the test machine:

alias update='sudo apt-get update && sudo apt-get upgrade'

Now I just have to type "upgrade" to bring the machine up to date.

Paying For Your Software - Testing

This is a theme I have touched on before. If you have been an avid
Linux consumer, you should consider becoming an avid Linux producer.
Great software doesn't write itself. There are many ways you can help
build the future of computing (and by the way, cheer leading is not one
of them). One way is by performing good software testing. I have
included some links (below) that document some of the tools and
techniques that Ubuntu recommend for testing and bug reporting.

Meanwhile, Back At The Ranch...

Work continues on cleaning up the production systems in preparation for
the upgrade. I also performed live CD tests on both systems to look for
possible hardware incompatibilities. I haven't found any on the desktop
system (yet) and the laptop has some minor video issues when booting.
Work will continue.

Further Reading

10.04 Beta 1 Release Notes:

- http://www.ubuntu.com/testing/lucid/beta1
Some advice on CD/DVD burning:

- https://help.ubuntu.com/community/BurningIsoHowto
- https://help.ubuntu.com/community/CdDvd/Burning
- Chapter 16 of The Linux Command Line covers various kinds of storage
media.

Tips and techniques for software testers:

- https://wiki.ubuntu.com/Testing
- https://help.ubuntu.com/community/ReportingBugs
- https://wiki.ubuntu.com/DebuggingProcedures
Other installments in this series:

- Project: Getting Ready For Ubuntu 10.04


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/23/2010 03:35:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

In this, our final installment, we will look at the screen terminal
multiplexing program. What the heck is a "terminal multiplexing
program?" I'm glad you asked.

Now that we have installed a bunch of interactive applications on our
workstations and SSH to allow remote access, we have a slight problem.
Is it reasonable for an interactive program (like mutt) monopolize our
terminal session? Isn't Linux multi-tasking? On the graphical desktop,
we can have many applications running at once and, by moving the mouse,
we can switch from application to application. Of course, on the
console, we can switch virtual terminals to provide multiple sessions
and if we are using SSH, remotely accessing our workstation from a
graphical desktop, we can open multiple terminal windows.

But there's another way. The screen program allows multiple sessions
inside a single terminal. You can create any number of sessions and can
even split screens to view two sessions at once. Further (and this is
the cool part), screen allows you to "detach" a session from a terminal
and later re-attach the session to a different terminal.

Installing And Running screen

By this time, we all know the drill:

me@linuxbox:~$ sudo apt-get install screen

will install the screen package. To run screen, we type screen at the
prompt followed optionally by the name of a program we want to execute
in the screen session. If no program is specified, screen launches a
shell. Try this:

me@linuxbox:~$ screen top

After you run this command, top will execute and everything will appear
normal. However screen is now managing the terminal session. screen
recognizes a large number of commands. You communicate with screen by
pressing Ctrl-a followed by a command letter. For example, to create
another session type Ctrl-a c and a new shell prompt will appear. There
are now two sessions running in the same terminal. We can cycle through
the sessions by repeatedly typing Ctrl-a n (for next).

Listing Your Sessions

The Ctrl-a " command displays a list of your screen sessions:



>From here you can use your up and down arrow keys to select a session
to display.

Scrolling And Copying

If you are using screen on a terminal session displayed in a graphical
terminal, you will notice that the normal scrolling mechanism no longer
works. This makes sense because if it did, your graphical terminal's
scroll back buffer would contain the jumbled contents of all of the
screen terminal sessions. screen manages its own scroll back buffers,
one for each screen session. To access the scroll back buffer (which is
called "copy mode" in the screen documentation), type: Ctrl-a [ and you
will be able to use up arrow, PgUp, etc to navigate the buffer. In this
mode (which uses many of the vi keyboard sequences) you can copy text
for later pasting. You do this by marking text. To mark text, you
position the cursor at the beginning of the text you want to copy and
press the space bar, then move the cursor to the end of the text you
want to copy and press the space bar again. The marked region is copied
into a paste buffer and screen exits copy mode. To paste the copied
text, type the screen command: Ctrl-a ]

Detaching And Reattaching Sessions

By far, the coolest feature of screen is its ability to detach and
reattach terminal sessions. Picture this scenario: you're at work and
you have just started a long running job on your work computer in a
terminal. With screen, you can detach the session, log off, go home,
reconnect with the your work computer, then reattach the still-running
job to your new terminal session.

Here is a demonstration (assuming we have another computer besides our
workstation, if not, you can use two virtual terminals on the
workstation):


- Start screen on the workstation and create a few sessions and put
applications in them. Try top, mutt, and irssi, for example.
- After the applications are running, move over to your second computer
and log into the workstation using SSH.
- On the second computer, enter the command screen -D -R into the
remote SSH session.
- Poof! All the screen sessions on the workstation are detached, you
are logged off of the workstation console, and all of the sessions are
reattached to the terminal running the SSH client on the second
computer. Pretty slick!

We've only touched on the capabilities of screen. It has many commands
and a configuration file that can be used to adjust many of its
features. See the links below for more detail.

In Conclusion

I hope you have enjoyed this series and that you continue to learn
about the applications and techniques that we have covered. While we
created a workstation that did not have a windowing system, the
programs we installed work just fine on graphical workstations too. The
text-based capabilities of Linux should never be overlooked. Text-based
applications are almost always faster and much less resource-intensive
than their graphical counterparts, so they make great additions to you
solutions toolbox.

Further Reading

The official GNU screen site and documentation:

- http://www.gnu.org/software/screen/
- http://www.gnu.org/software/screen/manual/
A screen tutorial from the Debian project:

- http://www.debian-administration.org/articles/34
A quick reference guide to screen (this site also contains a lot of
other well-written screen documentation):

- http://aperiodic.net/screen/quick_reference


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/18/2010 09:59:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Getting Ready For Ubuntu 10...

[William S. <bs...@pa...>]

Last time, we announced our intention to upgrade some of our systems to
Ubuntu 10.04, so what's next? To paraphrase a sight gag from an early
episode of South Park:



In this installment we are going to cover the planning phase of the
upgrade process. Good planning is often the difference between a good
upgrade experience experience and a bad one. As a computing environment
becomes more complex, planning becomes more essential. My environment
is fairly complex so I have to plan.

Objective

The first element to any good plan (and not just for OS upgrades) is a
clear objective. That is, in the broadest terms, what do we hope to
accomplish? In my case, I want to install Ubuntu 10.04 on two computers
(my main desktop system and my laptop) currently running Ubuntu 8.04
while maintaining all of the application set (and capabilities),
network integration, and user data.

Notice that I said install and not upgrade. I have learned through many
years of experience that upgrades don't really work. They kind of work
sometimes, but they never really work. Often, an OS upgrade is not able
to apply every new feature in the new version. For example, converting
an existing file system to a new file system type is often impossible.
Also, I don't want to reuse my existing configuration and settings
files. I want to reconfigure based on the new default configuration,
again to take advantage of everything the new release has to offer.

I know (from scanning the forums) that a lot of people are content to
just pop in an installation CD and push the upgrade button and hope for
the best. Then those same people start crying because they get a black
screen when they reboot, or their wireless stops working, or their
sound is busted, etc., etc., etc.

System Survey

Since our objective states that we have to maintain the application
set, network integration and user data, we better figure out what that
is. We do that by performing an inventory of our existing system Here
are some things to keep an eye on:


- Required Applications. When performing your system survey, go through
the application menus and list everything you rely on. In an upcoming
installment we will write a script that will prepare a package list to
compare against the new installation to ensure that we reinstall all
the apps that we care about. If you use Firefox, pay special attention
to bookmarks, stored passwords, and add-ons.
- Network Services. My workstations mount file systems on NFSv4 and
Samba shares. I also use an LDAP database to manage my address book.
- Hardware Features. We will want to make sure that all of our hardware
is working. During the testing phase we will cover video, sound, wired
and wireless networking, CD/DVD reading and writing, printing,
scanners/cameras, and USB devices
This is also a good time to do some system maintenance. Between
cleanings, computers get a lot of application and data buildup. I have
added many applications to my base system, some of which I use and
others which I don't. It's good to make a list and decide what you
really want on your "new" computer and what you can live without. The
same goes for data. Do you really need all those video files? See if
you can clear a few gigabytes off that disk. It will make things easier
later.

Testing

We're going to get involved with Ubuntu 10.04 starting with the Beta 1
release scheduled for release on March 18. I have a test computer
prepared where I will attempt to build approximations of the finished
systems. In doing so, I will be able to see what, if anything, blocks
my desired configuration. It also provides a chance to look at the new
features in this release, as well as alternate applications. We will
also use live CDs to test the hardware support on the real systems.

Installation

Once the final release of Ubuntu 10.04 occurs on or about April 29, we
should be ready to install. We'll make our installation media, create
and verify our final system backup, perform the installation, and
restore any additional applications.

Configuration

The final phase of the project is adjusting the configuration of the
new system to our liking. This will involve recreating accounts and
application settings. We will also restore the user data from our
backups.

After everything is restored and configured we will verify that
everything is in order. The very last step is to re-enable the system
backups and begin using the systems for production use.




--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/16/2010 04:19:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

Don't touch that dial! Even the most die hard GUI fans among you will
enjoy this.

You may have noticed that throughout this series, I have posted screen
shots of the applications used on our all-text Linux workstation;
screen shots that obviously are taken from a graphical desktop, so what
gives? Am I lying about this being an all-text workstation? Not at all.
I do take the screen shots on a graphical desktop. How? By logging in
to the workstation remotely from another computer.

One of the great joys of Unix-like operating systems (such as Linux) is
the way they work with networks. Much of the Internet's technology was
developed on Unix systems and it shows. Ever wonder why URLs use
forward slashes? Unix pathnames!

Back in the early days of my Unix career (the mid-1990s), there was a
idea going around (foisted by the marketing people at Microsoft) that
the newly introduced Windows NT was going to rapidly "kill" Unix. Real
Unix people knew this to be patent nonsense (though many of their
pointy-haired bosses did not) because NT lacked an essential feature.
It didn't support remote administration. I remember system admins
complaining bitterly about how to fix even simple problems on NT, they
had to travel to the machine and work the graphical interface
personally. Meanwhile, my team and I were managing a national network
consisting of hundreds of Unix workstations and servers from our little
office. The only time we ever had to travel to a site was to replace
hardware.

Over the years, there have been several Unix technologies used to
perform remote administration. Today, the overwhelming favorite is SSH
(Secure SHell). SSH allows the creation of a secure encrypted tunnel
between machines through which can flow any number of network
protocols. It's most common use however is simple command line access
to a remote system.

It works like this: a local machine runs a SSH client program that
talks to a remote machine running a SSH server. Every Linux system I
have ever used comes equipped with a SSH client but most distributions
do not install the server by default. This is unfortunate since almost
every system can benefit from remote administration.

Installing The OpenSSH Server

The most popular SSH implementation in the Linux world comes from the
OpenBSD project. It's called OpenSSH. It is usually broken into two
packages: the openssh-client package and the openssh-server package.
The client package is usually installed by default but we will need to
install the server package on our workstation. We can do this with the
following command:

me@linuxbox:~$ sudo apt-get install openssh-server

That's all there is to it. After the package installs, the service will
start and our workstation can now be remotely accessed. To demonstrate,
we will open a terminal window on another machine on our network and
use the SSH client program (called ssh) to log into our workstation:

bshotts@twin2:~$ ssh me@linuxbox
The authenticity of host 'linuxbox (192.168.1.7)' can't be established.
RSA key fingerprint is bf:bb:0e:9b:af:a1:dd:e0:b6:44:48:79:97:2f:34:97.
Are you sure you want to continue connecting (yes/no)? yes

The ssh program is invoked with this syntax:

ssh [user@]hostname

where user is an optional user name and hostname is the network name
(or IP address) of the machine we want to connect with. If the user
name is omitted, ssh defaults to the name you are currently using on
the local system.

The first time you connect with a remote system, ssh warns you that it
has never seen this remote machine before. One of the security features
of SSH is that it authenticates the remote systems you talk to. This
ensures that the machine you are talking to really is the machine you
think it is.

After answering "yes" to the prompt, ssh adds the remote system to its
list of remote hosts that it will recognize in future sessions:

Warning: Permanently added 'linuxbox' (RSA) to the list of known hosts.

Finally, it prompts you for the user's password on the remote system.

me@linuxbox's password:

Once that is entered, you are logged in!



>From here, you can use any of the applications on the workstation just
as if you were sitting in front of the workstation's console.

To end a SSH session, use the exit command:

me@linuxbox"~$ exit
Connection to linuxbox closed.
bshotts@twin2:~$

Executing A Single Command On A Remote System

We can also use the ssh program to remotely execute a single command on
our workstation. For example, we could ask our workstation about its
uptime and load:

bshotts@twin2:~$ ssh me@linuxbox uptime
me@linuxbox's password:
13:58:39 up 2 min, 0 users, load average: 0.10, 0.14, 0.06
bshotts@twin2:~$

If a command follows the hostname, ssh will execute the command on the
remote system and the command's output is transferred to the local
machine for display.

Copying Files Using SSH

In addition to the ssh program, the openssh-client package also
provides two additional programs used for securely copying files to and
from remote systems. The first is scp (secure copy) which is used much
like the regular cp command. To copy a file named somefile.txt to the
home directory of user me on the workstation, we would do this.

bshotts@twin2:~$ scp somefile.txt me@linuxbox:
me@linuxbox's password:
somefile.txt 100% 10 0.0KB/s 00:00

To place the file in a specific directory (and/or rename the file) on
the remote system, follow the hostname with the pathname of the desired
destination:

bshotts@twin2:~$ scp somefile.txt
me@linuxbox:/user/local/share/shared_file.txt

The second file copying program is sftp (secure ftp) which is a version
of the ftp program that uses SSH for transport. Remember, the ordinary
ftp program sends all of its data over the network unencrypted
(including user names and passwords), making it unsuitable for use over
the Internet.

Using The GUI With OpenSSH

The sftp protocol makes another feature possible. Most graphical file
managers support it. From our graphical desktop we can move files to
and from the remote workstation. Here's how:

In GNOME, we go to Places -> Connect to Server... and fill out the
dialog as follows:





We will next be prompted for the password on the remote workstation:




After that, voila! We're browsing the file system on the remote
workstation:




Adding Additional Users

With the ability to remotely connect to our workstation, it would make
sense to add some user accounts. This way, more than one person can be
using the workstation at the same time. To add a user account for an
imaginary user named "user1", we would do this:

me@linuxbox:~$ su -
Password:
linuxbox:~# adduser user1
Adding user `user1' ...
Adding new group `user1' (1001) ...
Adding new user `user1' (1001) with group `user1' ...
Creating home directory `/home/user1' ...
Copying files from `/etc/skel' ...

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Changing the user information for user1
Enter the new value, or press ENTER for the default
Full Name []: Workstation User 1
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y

linuxbox:~# exit
logout
me@linuxbox:~$

Now user1 can log in to the workstation with the command:

ssh user1@linuxbox



Deleting A User Account

This command will remove the above user account, if desired:

deluser --remove home user1

Invite Your Friends!

Next time you have your Linux buddies over with their laptops, surprise
them with individual user accounts on your awesomely configured
all-text workstation. You'll be the hit of the party!

Further Reading

The man pages for ssh, scp, sftp

SSH is covered in The Linux Command Line (Chapter 17):

- http://linuxcommand.org/tlcl.php
OpenSSH:

- http://en.wikipedia.org/wiki/OpenSSH
- http://www.openssh.com/
- http://www.openssh.com/faq.html
Windows users need not feel left out. PuTTY is a popular SSH client for
Windows:

- http://www.chiark.greenend.org.uk/~sgtatham/putty/




--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/11/2010 03:24:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Linux News: Ubuntu Is Making An Inro...

[William S. <bs...@pa...>]

I read an interesting article in InfoWorld today about how Ubuntu is
gaining market share in servers; a market long dominated by Red Hat.
You can see the article at:

http://www.infoworld.com/d/open-source/ubuntu-ready-run-your-business-servers-646?source=IFWNLE_nlt_openenterprise_2010-03-10

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/10/2010 04:56:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Getting Ready For Ubuntu 10...

[William S. <bs...@pa...>]

As you have probably heard, the next release of Ubuntu, 10.04 ("Lucid
Lynx") will occur during the final days of April 2010. My production
systems (the ones on which I do my writing and photography) are running
Ubuntu 8.04 and I have decided to upgrade them to the upcoming version.
This is the first of five-part series that will document my transition
to the new version.

The 10.04 version, like the earlier 8.04 and 6.06 releases, is a
so-called LTS or Long Term Support version of Ubuntu. This means that
it receives security and bug fixes (but not application version
upgrades) for a period of three years. This differs from the usual
eighteen month support period for ordinary Ubuntu releases. I have used
the LTS versions for several years and feel that it is the best choice
for my production systems. I use a lot of Linux distros in my work, but
for the machines I must rely on, I choose stability over the latest
features. For example, my server systems are running CentOS 4 which
first appeared in early 2005 and is still supported by Red Hat and the
CentOS team. In fact, the main reason I switched from Red Hat (Fedora)
to Ubuntu for my desktop systems was the availability of the Long Term
Support versions, a feature that Fedora does not offer.

The Opportunity

In a past life, I ran the QA department of a software company and I
often employ these skills to perform software testing on new Linux
releases. This case will be no different. The first beta release of
10.04 is scheduled for March 18 so we will begin our work then. Testing
is not just something I do for fun (it isn't) but it's important to
look for problems that might interfere with the deployment. By checking
for problems now, we have a better chance of getting them fixed before
the final release.

The Mission

Our mission is to upgrade the production systems while preserving the
existing data and functionality of the current systems. We'll also look
for exciting new features and applications that will enhance their
productive capacity. We will probably do a little scripting and system
administration along the way, too :-)

The Players

The two production systems involved are my Dell Inspiron 530N (which
originally shipped with Ubuntu 8.04 factory installed) and my IBM
ThinkPad T41 laptop. We'll also use my main test computer, a Dell
Dimension 2400N which is currently hosting our All-Text Linux
Workstation. We might also take a look at the 10.04 Netbook Remix
version to see if it offers any compelling reasons for upgrading my two
netbooks, which are now running 9.04 UNR.

Stay tuned. This ought to be fun.

Further Reading


- Ubuntu LTS
- Lucid Lynx Release Schedule
- Lucid Lynx Technical Overview





--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/09/2010 02:29:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

In this installment, we're going to take a another look at messaging,
this time focusing on Internet Relay Chat (IRC).

IRC is a popular text-mode application that finds wide use on a number
of platforms. Of most interest to us, is its use as a tech support
tool. IRC works by allowing a client program talk to a server that is
part of an IRC network. Multiple users connect to the server and
organize conversational groups called channels. Channels are
topic-oriented and cater to a wide variety of interests. The
participants of a channel then can converse with one another via a
scrolling text display.

The centerim program we recently installed supports IRC in addition to
a number of other popular messaging protocols, however, in this
installment we will install a dedicated IRC client called irssi. To
install irssi, we simply:

me@linuxbox:~$ sudo apt-get install irssi

To run irssi, we enter the command:

me@linuxbox:~$ irssi

and the initial screen will appear:



The first window displayed by irssi is called the status window. It is
used to display information about server connections and other status
messages. The initial message in the status message is useful as it
points us to the program documentation and some specific connection
instructions to join the Debian channel at Debian's own IRC server.

As you type, your input is displayed at the bottom of the screen.
Entries starting with a slash character are interpreted as IRC commands
and everything else as a message to post. To connect to the Debian
server we type the following command:

/connect irc.debian.org



It will take a few seconds to connect.

By default, irssi will use your system user name as your "nick" or
nickname during an IRC session. It's possible that your user name will
conflict with an existing name already registered by a user of that
server. In that case, we will get something like this:



To overcome this problem, we need to choose another nickname. That is
is done by entering this command:

/nick new_nickname

where new_nickname is the name you wish to use. In the examples that
follow, we will use the nickname "linuxbox", but you should make up
your own. We enter:

/nick linuxbox

and if we're successful, the status window will respond:

You're now known as linuxbox

Now that we have a connection to the IRC server, we next need to join a
channel. Channel names start with a the # symbol. We can join
the #debian channel by entering this command:

/join #debian

Next, we will see a list of all the members of the channel scroll by in
another window which overlays the status window.



The prompt at the bottom of the screen changes to indicate that we are
in a different window. Within a window, we can use the PgUp and PgDn
keys to scroll the window's contents and we can use the Ctrl-p
(previous) and Ctrl-n (next) keys to cycle through the available
windows.

As we observe the #debian window, it will slowly scroll as members post
questions and answers. If you are not familiar with IRC, you should
consult a good tutorial and observe the general practices of the group
before jumping in. Most channels also post links to official guidelines
for the channel's use. You can see the guidelines for the #debian
channel here.

To end our session, we enter this command:

/quit

Filtering Output

The default configuration of irssi displays a lot of non-message text
in channel windows announcing the comings and goings of members:



To filter this out of a channel, you can use a command like this:

/ignore -channels #debian * JOINS PARTS QUITS NICKS

Saving Your Settings

As you go through the irssi documention, you will see that irssi has a
lot of features and capabilities. After you have changed your settings,
such as adding the filter above, you can store your changes by entering
the command:

/save

and your changes will be added to the ~/.irssi/config file.

Another Server To Try

Many Linux and FOSS projects have official support channels on
Freenode. You can reach the Freenode server at irc.freenode.net. Try
the #ubuntu, #fedora, etc. channels there.

Further Reading

IRC tutorials:

- http://irchelp.org/irchelp/irctutorial.html
- http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial
- http://wiki.debian.org/DebianIRCChannelGuidelines
General IRC background:

- http://en.wikipedia.org/wiki/Internet_Relay_Chat
- http://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands
Freenode:

- http://en.wikipedia.org/wiki/Freenode
- http://freenode.net/
irssi documentation:

- http://www.irssi.org/documentation/startup
- http://www.irssi.org/documentation/tips
- http://www.irssi.org/documentation




--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/03/2010 09:00:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] dialog

[William S. <bs...@pa...>]

Now that we have covered launching a script from the GUI, it's time to
look at how to make our scripts a little more "graphical."
Interestingly, there are a number of tools that we can use to produce
user interfaces for shell scripts. In this installment, we will
concentrate on the most mature of these tools, dialog.

The dialog program lets scripts display dialog boxes for user
interaction. It does this in a text-based manner, using the ncurses
library. It can produce a variety of user interface elements and can
pass user input back to a script for processing. The dialog package is
not installed by default on most Linux distributions, but is readily
available in most distribution repositories.

dialog has been around for a long time and has gone through a number of
incarnations. The current version (which is maintained by the Debian
project) contains a number of features not found in earlier versions.

To demonstrate a few of the powers of dialog, we will write a script
that displays a series of dialog boxes and provide some ideas of how to
work with the output. We'll start the script with the following code:


#!/bin/bash

# dialog-demo: script to demonstrate the dialog utility

BACKTITLE="Dialog Demonstration"

# message box

dialog --title "Message Box" \
--backtitle "$BACKTITLE" \
--msgbox "This is a message box which simply\
displays some text and an OK button." \
9 50

The script invokes the dialog program with a series of options to set
the title for the dialog box, the title for the background screen, the
dialog box type (in this example a message box), the text to appear in
the box and the size of the box (9 lines high by 50 characters wide).
When we run the script we get the following results:



Next we'll add the following code to the end of the script to generate
another kind of dialog called a yes/no box. In addition to the dialog
box itself, we will also include some code to act on the results of the
user's selection:

# yes/no box

dialog --title "Yes/No Box" \
--backtitle "$BACKTITLE" \
--yesno "This is a yes/no box. It has two buttons." \
9 50

# examine the exit status and act on it
case $? in
0) dialog --title "Yes" \
--backtitle "$BACKTITLE" \
--msgbox "You answered \"Yes\"" \
9 50
;;
1) dialog --title "No" \
--backtitle "$BACKTITLE" \
--msgbox "You answered \"No\"" \
9 50
;;
255) dialog --title "Esc" \
--backtitle "$BACKTITLE" \
--msgbox "You pressed Esc" \
9 50
;;
esac

The yes/no box offers the user three choices: yes, no, and a cancel
which occurs if the Esc key is pressed. To select a button, the user my
use the Tab key to switch from button to button or, if dialog is being
run inside a terminal emulator on a graphical desktop, the mouse may be
used to select a button.

dialog communicates the user's choice back to the script via its exit
status. In the code that follows the yes/no box, we evaluate the exit
status. If the yes button is pressed, the exit status is 0, if the no
button is pressed, the exit status is 1, and if Esc is pressed, the
exit status is 255.




dialog can provide more than just simple button presses. It can support
edit boxes. forms, menus, file selectors. etc. When returning more
complex data, dialog outputs its results on standard error. To
demonstrate how this works, we will insert the following code near the
beginning of the script (just after the BACKTITLE=... line) to define a
function (read_tempfile) that will display the dialog output:


TEMPFILE=/tmp/dialog-demo.$$

read_tempfile() {

# display what is returned in the temp file

local tempfile

# read file contents then delete
tempfile=$(cat $TEMPFILE)
rm $TEMPFILE

# message box to display contents
dialog --title "Tempfile Contents" \
--backtitle "$BACKTITLE" \
--msgbox "The temp file contains: $tempfile" \
0 0
}

Next, we will add the following code to the end of our script to
display a menu box:

# menu

dialog --title "Menu" \
--backtitle "$BACKTITLE" \
--menu "This is a menu. Please select one of the following:" \
15 50 10 \
1 "Item number 1" \
2 "Item number 2" \
3 "Item number 3" 2> $TEMPFILE

read_tempfile

This code displays a menu containing three items. Each item consists of
two elements; a "tag" which is returned when a choice is made and
an "item string" which describes the menu selection. In the example
code above, we see that the first menu item has the tag "1" and the
item string "Item number 1." When we execute the code, dialog displays
the following menu:



To capture and display the output of the menu, we redirect the standard
error of dialog to the file named in the constant TEMPFILE. The
read_tempfile function assigns the contents of the temporary file to a
variable (tempfile) and passes it to dialog to display in a message
box. After the menu is displayed and a selection is made by the user,
the message box appears and displays the data returned to the script.

Next, we will add a checklist dialog by adding the following code to
the end of the script.

# checklist

dialog --title "Checklist" \
--backtitle "$BACKTITLE" \
--checklist "This is a checklist. Please from the following:" \
15 50 10 \
1 "Item number 1" off \
2 "Item number 2" off \
3 "Item number 3" off 2> $TEMPFILE

read_tempfile

As we can see, this code is almost the same as the code used to create
the menu dialog. The main difference is that the items in the checklist
add a third field called "status." The value of status may be
either "on" or "off" and will determine if a selection is already
selected or deselected when the program is run:




The user may select one or more checkbox items by pressing the space
bar.

Next, we will add the following code to the end of the script to
display a file selector:

# file selector

dialog --title "File Selector" \
--backtitle "$BACKTITLE" \
--fselect ~/ 10 30 2> $TEMPFILE

read_tempfile

For the file selector, dialog is passed the base directory for the
selection (in this example the directory ~/) and the size of selector.
For this example we specify 10 files in the list and a 30 character
wide dialog.




I think the file selector is easy to code, but awkward to use. You move
around the dialog with the Tab key and select directories and files
with the space bar.

One of the more novel types of boxes provided by dialog is the "gauge"
which displays a progress bar. To try out this feature, we will add
this code to the end of the script:

# gauge

# generate a stream of integers (percent) and pipe into dialog

percent=0
while (( percent < 101 )); do
echo $percent
sleep 1
percent=$((percent + 10))
done | dialog --title "Gauge" \
--backtitle "$BACKTITLE" \
--gauge "This is a gauge. It shows a progress bar." \
0 0

The gauge dialog does not output anything, rather it accepts a stream
of integers (representing the percent of completion) via standard
input. To provide this, we create a while loop to generate the stream
of integers and pipe the results of the loop into dialog. When the
script runs, the stream of numbers causes the progress bar to advance:



Note too, that we specified the size of the dialog as 0 0. When this is
done, dialog attempts to auto-size the box to fit in the minimum
necessary space.

Finally, we'll add another of the novel dialogs, a calendar:

# calendar

dialog --title "Calendar" \
--backtitle "$BACKTITLE" \
--calendar "This is a calendar." \
0 0 \
0 0 0 2> $TEMPFILE

read_tempfile

The calendar dialog box is given a date in day month year format. If
the year is specified as zero, as it is in this example, the current
date is used. The user can then select a date and the date is returned
to the script.




This concludes our brief look at dialog. As you can imagine, dialog can
be very handy for adding improved user interfaces for those scripts
that require it. While we have covered its general themes, dialog has
many more options and features. Check out the documentation link below
for the complete story.

Further Reading

Documentation for dialog:

- http://invisible-island.net/dialog/manpage/dialog.html
Other dialog-like programs:

- http://library.gnome.org/users/zenity/stable/
- http://xdialog.free.fr/doc/index.html


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
3/01/2010 12:25:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

Now that we have email working on our system, it's time to consider
other types of communication tools, in particular, messaging. Text
messaging is a very common form of communication today, often
surpassing email as way of sending short bursts of small messages.
Messaging actually has its roots in early Unix with the development of
the write and talk programs in the late 1970s While both talk and write
were used to communicate with multiple users sharing a single machine,
messaging today generally involves users scattered all over the globe
using the Internet.

There are many popular messaging protocols such as AIM (AOL Instant
Messenger), Jabber, MSN, IRC, and others and many client programs that
support one or more of these protocols. Many Linux users are familiar
with Pidgin, a graphical, multi-protocol, messaging client.

In this installment, we will install a text-based analog to Pidgin
called centerim, a fork of an earlier messaging client program called
centericq.

On our Debian workstation, we can easily install centerim this way:

me@linuxbox:~$ sudo apt-get install centerim

After the program is installed, we can invoke it like so:

me@linuxbox:~$ centerim

The first time centerim runs, it displays a two-part configuration
screen which is used to configure accounts and other stuff:







To demonstrate centerim in action, we'll configure an AIM account. On
the second configuration screen, we'll scroll down until we get to the
AIM protocol:




Next, we'll enter our account information including our AIM screen name
and password:




After we have the account defined, we use the right arrow key to
select "Done." Next, centerim displays our chat window:




Pressing the Esc key twice will take you to the top level menu and from
there you can go back to the configuration screens (F4) or quit the
program (q).

Further Reading

Centerim and centericq:

- http://en.wikipedia.org/wiki/Centerim
- http://www.centerim.org
- http://www.centerim.org/index.php/Documentation
- http://thekonst.net/centericq/
Historical background on text messaging:

- http://en.wikipedia.org/wiki/Instant_messaging
- http://en.wikipedia.org/wiki/Talk_(software)
- http://en.wikipedia.org/wiki/Write_(Unix)


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/24/2010 12:29:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Launching Shell Scripts In GNOME

[William S. <bs...@pa...>]

Today, we're going to look at how you launch a shell script (or other
terminal-based application) in GNOME. We are all familiar with
launching applications from the command line. There are advantages to
this even for for graphical applications. When you launch an
application on the command line, you can see what is produced on
standard output and standard error, which can sometimes provide
valuable diagnostic information. On the other hand, there is something
to be said for double-click convenience as well.

We will write a tiny shell script and then set up GNOME to allow
launching the script from a desktop icon. Here's the script we will use:

#!/bin/bash

# touch_foo - Script to touch the file "foo"

if [ ! -d foo ]; then
touch foo
echo "foo is touched."
else
echo "foo is a directory."
fi

Pretty simple. This script touches a file name "foo" but if a directory
with that name already exists, it displays a message and exits. We will
enter this script into our text editor and save it as ~/bin/touch_foo.

Next we need to create a launcher for the script. To do this, we right
click on the GNOME desktop and select "Create Launcher...":


A dialog box will appear where we can enter information about the
launcher:


Since we want to see the script execute, we will select "Application in
Terminal," otherwise the script will execute silently in the background:


Next, we give the launcher a name, browse for the script file, and fill
in an optional comment:


You may also click on the icon at the right of the dialog box and
select another icon for the launcher. After the dialog box is filled
out, we can click the OK button and the launcher is created and it will
appear on the desktop. Double clicking on the new launcher icon
launches the script.

But there's a problem. The terminal appears for an instant and vanish.
Not exactly what we had in mind. What gives?

The problem is that when the script finishes, the terminal session
ends. To prevent this, we have to stop the script from finishing. We
could do this by having an endless loop at the end of the script, or by
including a read command which will wait for user input before
proceeding. We can adjust our script by adding a line at the end:

#!/bin/bash

# touch_foo - Script to touch the file "foo"

if [ ! -d foo ]; then
touch foo
echo "foo is touched."
else
echo "foo is a directory."
fi

read -p "Press Enter to continue > "

After making this change, a terminal will appear and wait until the
Enter key is pressed:


Another Approach

Another way we can configure commands for the launcher is to directly
launch gnome-terminal and pass the desired command as an argument. This
allows us to control the configuration of the terminal. For example we
can set the window title, window geometry, and terminal profile used
with our command. Here is a command we can use to launch the top
program and set the window title to "Top":

gnome-terminal -e /usr/bin/top -t Top

Note however, that if you want to run shell scripts this way, you must
construct the command this way:

gnome-terminal -e 'bash -c touch_foo'

including the bash program in the command so that there is a program
present that can interpret your script.

Further Reading

- gnome-terminal man page
- bash man page (OPTIONS section)


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/19/2010 04:34:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] tput

[William S. <bs...@pa...>]

In a recent post, we covered a technique that can produce colored text
on the command line. Today, we will look at a more general approach to
producing not only text effects, but also gaining more visual control
of our terminal.

A Little History

Back in the old days, when computers were connected to remote
terminals, many brands of terminals existed and they were all a little
different in terms of their feature sets and capabilities. As a result,
different terminals used different sets of commands to control them.

Terminals responds to codes (called control codes) embedded in the
stream of text sent to them. Some of these codes are standard and
familiar like carriage return and line feed. Others, like those to turn
on bold text or underlining are not. Terminals can, in fact, perform
many kinds of functions. As microprocessors became available and the
advent of the personal computer loomed, terminals became
increasingly "smart" and feature laden.

However the proliferation of terminal brands and feature sets posed a
problem for software developers. Software had to be painstakingly
customized to support a particular terminal. What was needed was a
software system that supported hardware independence so that
applications could use a standard set of commands to deal with any
terminal. This problem was addressed in two ways. First a standard set
of control sequences were developed by ANSI (American National
Standards Institute) and adopted (in varying degrees) by terminal
manufactures to give all terminals a common set of commands. We looked
at the ANSI commands in a an earlier post. The second approach was
development of an intermediary layer (much like today's notion of a
device driver) that translates a standardized command into the specific
control codes used by a particular terminal.

In the Unix world, there are two such systems, the original, termcap
and the more recent terminfo. Both contain a database of control code
sequences used by different kinds of terminals.

Enter tput

tput is a command that can query the terminfo database to see if a
particular terminal can support a particular feature. It can also
accept terminal commands and output (via standard output) the control
code sequences for that terminal. tput is generally used like this:

tput capname [parameters...]

where capname is the name of a terminal capability and parameters are
any option parameters associated with the specified capability. For
example, to output the sequence of instructions needed to move the
cursor to the upper left corner of the screen (the "home" position):

tput cup 0 0

which means cursor position row 0, column 0.

Since tput actually outputs the sequence to standard output (you won't
see the sequence since it is interpreted by your terminal emulator as
an instruction), you can store the sequences in variables. Here we will
store the sequences to control bold text:

bold_on=$(tput bold)
bold_off=$(tput sgr0)

Now, to highlight some text, you could:

echo "This is ${bold_on}important${bold_off}."

and you get this:

This is important.

There are a huge number of terminal capabilities, though most terminals
only support a small subset. Besides changing text colors and
positioning the cursor, it is possible to erase text, insert text, and
control text attributes. The terminfo man page lists all the terminal
capabilities and the Bash Prompt HOWTO section 6.5 (see "Further
Reading" below) describes the ones most useful for ordinary screen
control.

Before we leave, here is a version of the prompt_colors script that
uses tput to set foreground and background text colors:

#!/bin/bash

# prompt_colors -- demonstrate prompt color combinations.

for fore in {0..7}; do
set_foreground=$(tput setf $fore)
for back in {0..7}; do
set_background=$(tput setb $back)
echo -n $set_background$set_foreground
printf ' F:%s B:%s ' $fore $back
done
echo $(tput sgr0)
done

Further Reading

- tput man page

- terminfo man page

- http://en.wikipedia.org/wiki/Computer_terminals

- http://en.wikipedia.org/wiki/Terminfo

- http://en.wikipedia.org/wiki/Tput

- http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x405.html

- http://tldp.org/HOWTO/Text-Terminal-HOWTO.html


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/17/2010 05:38:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] All Creative Work Is Derivative

[William S. <bs...@pa...>]

A little something to hold you over...









--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/15/2010 02:35:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Prompt Tricks 2

[William S. <bs...@pa...>]

I'm a little behind because of all the snow, but fortunately ace book
reviewer Mark Polesky has come to my rescue with some feedback on my
previous post. He writes:

That's a pretty cool script, but the formatting of the
output is a little sloppy. If nothing else this line is in
the wrong place:

printf '\033[0m'

Here's a much cleaner version using bash.

- Mark

* * * * * * * * * *

#!/bin/bash

# prompt-colors -- demonstrate prompt color combinations.

for attr in 0 1 4 5 7; do
echo
printf "ESC[%s;Foreground;Background\n" $attr
for fore in {30..37}; do
for back in {40..47}; do
printf '\033[%s;%s;%sm %02s;%02s ' \
$attr $fore $back $fore $back
done
printf '\033[0m\n'
done
echo
done
Good job, Mark (he has become a real command line ninja since he read
my book from cover to cover as a reviewer).

One of the interesting things Mark did in converting the script from
plain sh to bash was to employ brace expansion in the for commands. For
example:

for fore in {30..37}; do

This expansion results in a sequence of numbers from 30 to 37
inclusive, a good technique to know.

But what if you need to produce a sequence of number that increment by
a value other than one? Let's say that you only wanted odd numbers from
1 to 7? In this case, you could code the sequence literally:

for i in 1 3 5 7; do

That's easy, but what about a sequence from 1 to 777? Not so easy.

To produce a large sequence, you can use the seq command. It works like
this:

seq [-options] [first [increment]] last

where first is the first number in the desired sequence, increment is
the size of the step between each member of the sequence and last is
the last number in the sequence. For example, to produce a sequence of
odd numbers from 1 to 777, we would do this:

for i in $(seq 1 2 777); do

The seq command is also handy if you need to ensure that a script can
run under sh since sh lacks the brace expansion feature of bash.

Well, that's all I have. Got to get back to shoveling!

Further Reading


- Chapter 8 of The Linux Command Line

- The seq man page


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/13/2010 10:19:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Prompt Tricks

[William S. <bs...@pa...>]

Kind book reader Bruce Fowler sent me a note shortly after the book was
released providing some feedback on Chapter 14, "Customizing The
Prompt." He pointed out (quite rightly) that there are many practical
things you can do with the shell prompt that can make your command line
experience easier and more enjoyable. One of his favorites was simply
coloring the shell prompt so that it is easier to see in a long stream
of text output.

Your shell prompt is defined by the contents of a shell variable named
PS1. The variable contains a combination of literal text and special
codes that expand into various elements of the prompt when it is
displayed. We can easily modify our prompt to give it the color green.

First, we'll save a copy of our current prompt string in a new variable
named PS1_OLD:

me@linuxbox:~$ PS1_OLD="$PS1"
Later, if you want to revert to the original prompt settings, you can
do this:

me@linuxbox:~$ PS1="$PS1_OLD"
Next, we'll add ANSI escape sequences to the beginning and end of our
prompt string to set the color to green and back to its original color:

me@linuxbox:~$ PS1="\[\033[01;32m\]$PS1\[\033[00m\]"
Now, we have a green prompt!

me@linuxbox:~$

Let's break this prompt string down:

Element Meaning \[ Beginning of non-printing sequence. You need to tell
bash that the sequence that follows does not actually print characters
on the screen (it only sends control instructions to your terminal
emulator setting the color). bash would otherwise count the characters
and this would mess up bash's calculation of the cursor position which
it does to support command line editing. \033[01;32m ANSI sequence to
set foreground text green. \] End of non-printing sequence. $PS1
Original prompt string. We're embedding the original prompt string in
the middle to retain its design. \[ Beginning of non-printing sequence.
Again, the sequence that follows to reset the colors does not print
characters on the screen. \033[00m Sequence to reset attributes and
color to previous settings. \] End of non-printing sequence.
To make this change permenent, add this line to your .bashrc file:

PS1="\[\033[01;32m\]$PS1\[\033[00m\]"
Bruce also suggested making the prompt for the root account (if your
system is so equiped) a different color (like red) to remind you that
you are operating as the superuser.

Finally, Bruce included a short script that he picked up from a USENET
group which displays all the possible color and attributes supported by
ANSI:


#!/bin/sh ############################################################ #
Nico Golde (nico(at)ngolde.de) Homepage: http://www.ngolde.de # Last
change: Mon Feb 16 16:24:41 CET
2004 ############################################################ for
attr in 0 1 4 5 7 ; do
echo "----------------------------------------------------------------"
printf "ESC[%s;Foreground;Background - \n" $attr for fore in 30 31 32
33 34 35 36 37; do for back in 40 41 42 43 44 45 46 47; do
printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back $fore $back done
printf '\n' done printf '\033[0m' done

When executed, the results look like this:

Further Reading

- Chapter 14 of The Linux Command Line

- Bash Prompt HOWTO

- The PROMPTING section of the bash man page

- ANSI Escape Codes


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/10/2010 09:25:00 AM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

In this installment, we'll finish up our look at email.

Now that we have mutt talking to the outside world, it would be handy
if we could also send messages from the command line as we did in Part
8 using the mail command. Fortunately, mutt supports the same technique.

Using mutt On The Command Line

We can send the output of a command to a remote email recipient via our
POP3 configuration using a command such as this:

me@linuxbox:~$ ls -l | mutt-p -s "test message" so...@so...
Here we used the alias "mutt-p" described in the previous installment.
Please note that if such an alias were used in a shell script, it would
most likely fail because the .bashrc file where the alias is defined is
not sourced by the copy of the shell executing the script. In such a
case, we would need to spell the command out fully:

mutt -F ~/.muttrc-pop3 -s "test message" so...@so...
Another Mail Client

While Debian installs mutt by default, it's not the only full-featured
text-based email client available. Another popular choice is Alpine,
the successor to the popular PINE email client from the University of
Washington. Alpine is similar to mutt in most respects though I think
it has an easier user interface:


In addition to the usual email functions, Alpine also sports its own
address book and Alpine's configuration is adjustable from within the
user interface so that editing the configuration files is not strictly
necessary, but its configuration is as complicated as mutt's.


Alpine configuration, top-level


Alpine configuration, down deep

Summing Up

Text-based email clients have a long and storied history in the Unix
world and remain the tools of choice for serious email users. As you
dig deeper into the documentation of mutt and Alpine, you will find
that nothing compares to the configurability of either of these
programs.

Further Reading

More support resources for mutt:

- http://mutt.blackfish.org.uk/

- http://therandymon.com/woodnotes/mutt/using-mutt.html

- http://hacktux.com/mutt/addressbook

- http://mark.stosberg.com/Tech/mutt.html
For Alpine:

- http://www.washington.edu/alpine/

- http://www.washington.edu/alpine/tech-notes/config.html

- http://www.ii.com/internet/messaging/pine/


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/05/2010 12:47:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Project: Building An All-Text Linux ...

[William S. <bs...@pa...>]

In our previous installment we saw how our Debian workstation supports
email between users on the system. This time we're going to add the
ability to send and receive email over the Internet.

One of the reasons that email is such a difficult subject to cover is
that there are so many different kinds of email tools and
configurations. For this lesson, we are going to create a really simple
configuration designed to satisfy the basic needs of a residential
user. It is certainly possible to create a much more sophisticated
configuration. In fact, with Linux, almost any kind of email setup is
possible, including huge enterprise-class solutions.

As we saw last time, our email client, mutt, reads mail messages that
it finds in a mailbox file located in /var/mail. To send mail, mutt
passes a composed message to the exim mail transport agent (MTA) for
delivery. So how do we send mail to the outside world?

The Traditional Way

The traditional way is to configure the MTA to communicate with a
smarthost, a remote server that can determine where the remote
recipient's mailbox is located and pass the messages to it. Such a
configuration can be easily created in Debian by telling the package
installer to reconfigure the exim4 package using a script built into
the package. This technique is good if your workstation is on a
corporate network and you have a mail server through which mail from
all users is sent and received. You can find a complete description of
this configuration process here.

Receiving mail is traditionally done by either configuring the MTA to
receive incoming connections from other mail servers, or by running a
mail delivery agent program (such as fetchhmail or getmail) that copies
the contents of remote mailboxes to the local mailbox.

However, the traditional approach is not well suited to our residential
workstation because each user may have different email providers, so we
need a solution that is potentially different for each user. Of course,
with enough configuration, the traditional approach can be made to
work, but it wouldn't be pretty.

The Client Centric Way

For those of you who have used GUI-based email clients like Evolution
or Thunderbird, the traditional way probably seems very alien and
complex. You have likely used a single email client program that
performs all the functions of the multi-program traditional method.
That's the approach that we'll try to take. Too bad mutt makes it so
hard.

The designers of mutt have taken the fairly stern view that a mail user
agent (MUA) should be a mail user agent and nothing more. In recent
years however, they have softened their stance on this issue somewhat
and now offer optional support for SMTP (Simple Mail Transport
Protocol) to communicate with smarthosts and POP and IMAP support for
reading mail on remote servers. Fortunately, the version of mutt
supplied with Debian has these optional features compiled in.

In the exercise that follows, we are going to configure mutt to use a
POP3 server and an external smarthost, and an IMAP server and an
external smarthost. By leaving the configuration of exim unchanged, we
will continue to send and receive local mail. Note that you will need
to adjust the configuration files listed below to fit your ISP's
specific requirements.

POP3 Configuration

The Post Office Protocol (POP) is an older and less sophisticated mail
delivery system. It is common among residential ISPs. To configure mutt
to download messages from a remote POP3 (POP version 3, the version
most often used today) and to send messages via a remote SMTP server
acting as the smarthost, we will create a mutt configuration file and
name it ~/.muttrc-pop3:


### POP3 setup for incoming mail

# File where incoming messages will be kept
set spoolfile=~/mailbox-pop3

# Your user name as understood by your ISP
set pop_user = "username"

# Your password as understood by your ISP
set pop_pass = "password"

# Host name of ISP's POP3 server
set pop_host = "mail.your_isp.com"

# Do not delete messages from POP3 server after downloading.
# Change to "yes" after testing.
set pop_delete = no


### SMTP setup for outgoing mail

# URL of ISP's SMTP server
set smtp_url = "smtp://username@mail.your_isp.com/"

# Password for SMTP server
set smtp_pass = "password"

# Your email address as understood by your ISP
set from = "username@your_isp.com"

# How you want your name to appear in email messages
set realname = "Your Name"

To execute this configuration, we invoke mutt this way:

me@linuxbox:~$ mutt -F ~/.muttrc-pop3

IMAP Configuration

If you have a good ISP, they will offer Internet Message Access
Protocol (IMAP) on their mail server. IMAP keeps your mail on the
server and allows you to maintain multiple folders and has a host of
other features lacking in the POP system. In the configuration below,
we will communicate with a remote IMAP server using SSL for encryption.
We will call this configuration file ~/.muttrc-imap.

Note: In order to use SSL authentication, make sure you have the
libsasl2-modules package installed on your system.


### IMAP setup for incoming mail

# Your email address as understood by your ISP
set imap_user = "username@your_isp.com"

# Your account password
set imap_pass = "password"

# Name of your ISP's IMAP server and folder locations
set folder = "imaps://mail.your_isp.com:993"
set spoolfile = "+INBOX"
set postponed="+/Drafts"

### SMTP setup for outgoing mail (using SSL)

# URL of ISP's SMTP server including SSL (smtps://) and port
# number (:465) as needed.
set smtp_url = "smtps://username@mail.your_isp.com:465/"

# Password for SMTP server
set smtp_pass = "password"

# Your email address as understood by your ISP
set from = "username@your_isp.com"

# How you want your name to appear in email messages
set realname = "Your Name"

### Files needed to store IMAP cache and SSL certificates

set header_cache=~/.mutt/cache/headers
set message_cachedir=~/.mutt/cache/bodies
set certificate_file=~/.mutt/certificates


To use this configuration, we need to create the directories for the
IMAP cache and for SSL certificate storage. We can create them with the
following command:

me@linuxbox:~$ mkdir -p ~/.mutt/cache/bodies

To execute this configuration, we invoke mutt like this:

me@linuxbox:~$ mutt -F ~/.muttrc-imap


Using Aliases To Support Multiple Configurations

We can simplify the invocation of mutt by adding these two lines to our
~/.bashrc file:

alias mutt-p='mutt -F ~/.muttrc-pop3'
alias mutt-i='mutt -F ~/.muttrc-imap'

There you have it. We now have mutt commands for handling local mail
(mutt), POP3 mail (mutt-p) and IMAP mail (mutt-i).

Further Reading

Background on mail protocols:

- http://en.wikipedia.org/wiki/Post_Office_Protocol

- http://en.wikipedia.org/wiki/Imap

- http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
Using mutt with Gmail via IMAP:

- http://crunchbanglinux.org/wiki/howto/howto_setup_mutt_with_gmail_imap
Mutt configuration samples:

- http://wiki.mutt.org/index.cgi?ConfigList


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
2/03/2010 03:40:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Some Site News

[William S. <bs...@pa...>]

- 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!


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
1/29/2010 04:55:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] Building An All-Text Linux Workstati...

[William S. <bs...@pa...>]

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:

- 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)
Some documentation on mutt:

- http://www.linux.ie/articles/tutorials/mutt.php

- http://www.mutt.org/doc/manual/


--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
1/27/2010 05:03:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] .bashrc vs. .bash_profile

[William S. <bs...@pa...>]

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.

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
1/22/2010 02:59:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] In Praise Of Panix

[William S. <bs...@pa...>]

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:

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

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
1/20/2010 03:16:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] The Linux Command - First Edition is...

[William S. <bs...@pa...>]

After a two year effort, I have released the first edition of "The
Linux Command Line" in all of it's 522 page glory!

I want to give special thanks to Mark Polesky for his extraordinary
review and test of the book, as well as the rest of the review team:
Jesse Becker, Tomasz Chrzczonowicz, Michael Levin, and Spence Miner.

Special thanks also go out to Karen Shotts for editing my so-called
English.

To download the free PDF version of the book, go to
https://sourceforge.net/projects/linuxcommand/files/ and get the file
TLCL-09-12.pdf.

You may also purchase a printed version of the book in large,
easy-to-read format (which is, in fact, very handy) by going to:
http://www.lulu.com/content/paperback-book/the-linux-command-line/7594184

Enjoy!

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
12/14/2009 01:53:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] The Linux Command Line - Fourth Draf...

[William S. <bs...@pa...>]

The fourth draft of the book is now available. This version contains
almost all the the review feedback received so far and has been edited
through the final chapter. This draft does not yet include an index,
but is otherwise close to being finished.

The new draft, named TLCL-09.11.pdf, is available here.

Enjoy!

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
11/19/2009 03:41:00 PM

[Linuxcommand-announce] [LinuxCommand.org: Tips, News And Rants] The Linux Command Line - Third Draft...

[William S. <bs...@pa...>]

The third draft is now available. This version features reformatted and
captioned tables, some of the changes suggested by the review team
(more to follow), and a number of small additions. It also includes the
edited versions of the first 18 chapters.

If you are working on the review, please switch to this version. The
new draft, named TLCL-09.10.pdf, is available here.

Thanks for your help!

--
Posted By William Shotts to LinuxCommand.org: Tips, News And Rants at
10/03/2009 11:46:00 PM