Linux Neophyte

Since migrating to Feisty at work I’ve found two fairly important problems. I guess the matter of importance depends on what you need to get done. I regularly need to mount/un-mount CIFS shares and I regularly need to use rdesktop to connect to other Windows machines. So, for me, these problems are big. I haven’t done a lot of research on the CIFS problem just yet, that’s for another post. If you’re having a Remote Desktop problem, read on for the fix.

There should be a fix for the rdesktop problem shortly, it’s in the testing phase now. Basically rdesktop is crashing and making it impossible to maintain a connection to a remote server. You’ll find details at https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/104332. I downloaded the proposed fix from http://archive.ubuntu.com/ubuntu/pool/main/r/rdesktop/rdesktop_1.5.0-1ubuntu1~prop1_i386.deb, installed it and promptly let go a sigh of relief. I am now able to connect and remain connected to my 2003 server. If you’re using rdesktop directly or TS Client and find that the program is crashing constantly, give the fix a shot.

written by M@ \\ tags: Feisty, Getting Help, Ubuntu

I’m still following the course over at LinuxBasics.org (and I’m waaaay behind at the moment). Chapter 6 is all about editors, and specifically the Vim editor. So for a least the next few posts, I’ll be composing in Vim and then pasting into Wordpress.

Vim is the editor I’ve been forcing myself to use since jumping into the Linux ring. I chose it because I had heard of it before, I had actually used a GUI version of it in Windows for a while to maintain a Windrop IRC bot, and because everything I had read online made it clear that Vim was a very common and powerful UNIX editor.

There are tons of sweet commands in Vim that allow you to keep your fingers on the keyboard at all times. IMO, much preferable to mousing around an editor (even when I couldn’t type, I still found the keyboard faster). The commands do (of course) require a little practice to really nail down. The good news is that there’s an extremely simple to follow tutor built into the program. To run it, simply enter vimtutor at the command line and follow the on-screen instructions. I did find this tutor back when I started using Vim, I went through it once to collect enough information to make using the editor bearable, now I’m actually taking some time to get this down. Unless you’re an elephant, you’ll probably need to run the tutor a few times.

I’ve re-read the last two paragraphs, it almost sounds like I dislike using Vim. That couldn’t be further from the truth. It’s got a learning curve to it, it requires some thought in the beginning and (fortunately) that eventually leads to muscle memory. It was a moderately tough road at the start. So indeed, in the beginning I had to force myself to use it and at times it was as frustrating as hell. That ends, and I’m very comfortable using it on a daily basis now (I admit that I’m still looking up commands from time to time). The more you use it the better it gets.

Whatever you do, don’t go starting up Vim without (at the very least) going through the tutor or checking out some online tutorials. One of the things that make it such a powerful editor is that it has two modes, command and input. When you first launch it, you’re in command mode. Unless you happen to enter an i, a or o as the first character, you’re going to find yourself a little confused and probably annoyed.

Vim is certainly worth snuggling up to if you want to hone some of your skills. If you’ve been exploring your system, you know that almost every configuration file is comprised of plain text and you need an editor to make changes to them. Since you’ll find Vim on just about any distro, you’ll want this weapon in your arsenal.

Note: If you’re using Edgy, perform a sudo apt-get install vim before getting started, it seems that Ubuntu defaulted to Vi (the inspiration for Vim) and IMO, it’s just a bit more difficult get used to.

For more help with Vim check out the links below:

*http://www.apmaths.uwo.ca/~xli/vim/vim_tutorial.html

*http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html (neat cheat sheet)

written by M@ \\ tags: Apps, CLI, Console, Edgy, Getting Help, Ubuntu, VIM

I’ve been playing around with redirection for the LBO course I’m following. I find what you can do with redirection fascinating (could be that I’m just easily amused). This is all command line work, so if you’re interested in honing your CLI-fu, read on. Some of this is really basic, some of it not so much.

NOTE: All of these commands should be executed with your regular user account. Don’t prefix the commands with sudo, don’t be operating as root.

First things first, you need to know a little about standard input, output and error. Standard input is usually your keyboard, standard out and standard error are usually your screen (or some window on your screen). Each of these 3 types of I/O (input/output) streams have an identifier associated with them called a file descriptor. In short, the file descriptor is an positive integer used to reference I/O.

* Standard input: 0
* Standard output: 1
* Standard error: 2

Before reading on, perform a man ls, man cat & man less to familiarize yourself with the commands we’ll be using.

A simple form of redirection can be illustrated with ls > dirlist. The greater than operator (>) redirects the results of ls to the file dirlist. If the file doesn’t exist when you execute the command, it will be created. If it does exist, it will be overwritten with the output from ls. After executing the command you can use cat dirlist |less to page through the contents of the file in your terminal. The cat command we issued to view the file uses another type of redirection that will be explained shortly.

In this example, you can append output to existing files with a double greater than (>>). If you want to keep a copy of your directory list with the time and date it was created appended to the bottom of the file you could execute date >> dirlist. Perform a cat dirlist to view the changes to the file.

In summary, using greater than (and double greater than), we’ve redirected standard output to a file instead of your screen. With the cat command we’ve redirected standard output from your screen to the input of another program (explained in the next section).

Before reading on, perform a man tee to familiarize yourself with the command we’ll be using.

You can also redirect the output from one program to the input of another. If you wanted to see the output of ls on screen as well as have it written to a file you could enter ls |tee dirlist. The vertical bar (referred to as pipe) character hands the output of ls to the program tee which writes its output to standard output (your screen) as well as a file.

The cat command back in step one worked the same way, the output from cat became the input for less and good ole’ less just spit its results to standard output and you got to read the file in pages.

So, it’s pretty simple to write output to files (> & >>), and it’s equally as simple to send output to other programs as input (|).

Here’s where the fun begins folks

Standard out and standard error are normally written to your screen, you would find any errors lines mixed in with non-error lines (this will be clear in a moment). We have the option of directing one or both streams to different locations. This is useful when performing a command that has gobs of results and we want to carefully review them. This is where the file descriptors for output and error come into play.

ls -R /etc/ 1> ~/goodnews 2> ~/badnews

This command performs a recursive directory listing of /etc redirecting the results of standard output (1>) to a file in your home directory named goodnews as well as redirecting standard error (2>) to a file named badnews. This command should return a few errors because of file permissions so execute the command and review the results. Pretty handy eh’?

Here’s my FAVORITE new toy. Not only can we send the results to files, but we can redirect output to other terminal sessions. Just for the joy of it, start 3 terminal sessions and arrange them so you can see them all at once. In each terminal, you will need to enter the command tty. The output will give you the device number of the current PTS (pts is a psuedo terminal). The results will look something like /dev/pts/x where x is a number. I’ll be using /dev/pts/8, 9 and 10.

In terminal that returned /dev/pts/8 I enter:

ls -R /etc/ 1> /dev/pts/9 2> /dev/pts/10

All of the non-error messages (standard output) are sent to /dev/pts/9 and all of the errors (standard error) are sent to /dev/pts/10. You can’t tell me that isn’t the coolest thing :).

These are just a few examples of redirection, there’s a lot more that you can do with it. Chapter 5 of the LBook on http://linuxbasics.org will give you more information and a series of useful exercises following the reading.

written by M@ \\ tags: BASH, CLI, Console, Getting Help

When I started this Linux thing, I was coming from a Windows environment, I had no experience with Linux and I was (and I still am) looking for any way to learn a little something about how things work. I honestly forget how I stumbled upon LinuxReality but I’m glad I did. This was the first podcast I’ve ever listened to and it’s GREAT. Chess Griffin hosts the show, he’s well spoken, knowledgeable and makes it extremely easy to get started with desktop Linux. He starts off very basic and builds (so yes, you should start with episode one). If you’re new to the scene, please take some time and check out his contribution. You won’t be sorry.

There are a lot of other Linux podcasts out there as well, they range from newb to intermediate and beyond. If you’re interested in checking them out, there’s a good list available at http://www.thelinuxlink.net.

written by \\ tags: Getting Help

In my last post I explained that the /usr/share/doc/ directory contains a LOT of information about the packages installed on your system. I noted that some of the documentation will be stored in .gz files and how to view them. It’s easy if you’re browsing with a graphical file manager, but what if you need to view the documents from the command line?

When I originally bumped into this I just assumed that I had to extract the documents with gunzip to read them. As a regular user, you don’t have write access to this location, I needed to sudo gunzip (on Ubuntu) or switch user to root and then gunzip the file (on Fedora). I always extracted to the same directory as the documentation so that I wouldn’t have to do it again next time. Being a newb I just figured, that’s how it’s done in Linux land. NOPE!

Enter zcat and zless, these programs work just like cat and less only they operate on compressed files. If you want to view the file Changelog.gz in the current directory you enter the command zless Changelog.gz. This will display the text file in your terminal window pausing so that you can read the document in pages. You could also enter zcat Changelog.gz, that would display the text file in your terminal window without pausing.

For those of you familiar with grep, you might like to know there’s a zgrep as well.

Handy stuff!

written by M@ \\ tags: Getting Help

This morning I read about a free on-line course being offered by LinuxBasics.org. The course starts on October 19, 2006 (next week), and is available to anyone with a thirst for Linux knowledge. The schedule hasn’t been posted yet, so I’m not exactly sure how tough it will be to meet the time requirements of the course. I’m certainly going to give it a shot.

Participants will read sections weekly and complete the exercises following each. There is a mailing list for discussion and help so that you can be sure you totally understand what’s going on. The mailing list is geared towards the newbie so you should feel confident asking any question that you may have.

If you’re interested, check out http://www.linuxbasics.org/course/start and the course material, http://www.linuxbasics.org/course/book/index.

written by \\ tags: Getting Help

Man pages are a great place to start when you need help using a program, however they don’t always get the point across in an easy to follow manner. This is especially true if you’re new to Linux. Most of the packages that you install will come with a man page (or several) as well as additional documentation. Both Fedora and Ubuntu tuck all of this additional information away in sub-directories off of the /usr/share/doc/ directory. There you can find such gems as FAQs, examples of configuration files, changelogs and more (depending on what the package offers). I should note here that I’ve found considerably less extra documentation in Fedora than I’ve found in Ubuntu.

Open up your file manager (for many of you it will be Konqueror or Nautilus) and browse to /usr/share/doc/, there you will find hundreds of folders named after the packages installed on your system. Find an application you’re familiar with and enter the folder. You can now view all of the extra documentation associated with that application.

Note: Depending on your distribution, many of these files might be kept in .gz (compressed) files. Double-click on the file to open it in your default archive manager, this will display the actual text file contained there-in. You can now double-click on the text file to read it’s contents.

written by \\ tags: Getting Help

In my last post I covered reading man pages via the console. Depending on your distro, you may find that man pages are available via your desktop’s GUI help center.

Ubuntu does this very well, while Fedora had some wonkiness.

Ubuntu/Gnome users can select System > Help > System Documentation. The Help Topics page contains a few categories dedicated to Ubuntu specific documentation, scrolling down will show Other Document Categories. Here you will want to click the Command Line Help link. You will be shown two more categories; GNU Info Pages and Manual Pages. Info pages tend to be more in depth where man pages give you the basics and then leave you to experiment. Once you select one of these categories, you’ll find yet another collection of categories, you can select one of them or simply enter the command you’re interested in learning about into the search field. Entering shutdown will give you the man page for the shutdown command.

Note: When I first entered the help center and attempted to search for some common commands, the results didn’t include any man pages. Once I browsed through some of the available man pages, the search results began including manuals. YMMV.

Fedora works much the same way, within Gnome you select System > Help. You’ll have fewer categories, but the command line help is there. I’ve found that browsing the command line help works perfectly, however I usually prefer to just search for what I want. Here is where Fedora has some issues. Entering shutdown into the search field results in the help center displaying a link to the man page, clicking on that link gives nothing more than an error about an invalid uniform resource identifier. My Google-fu might be lacking today, I just can’t locate any fixes for it.

If you’d rather not read your man pages via the terminal, this is the graphical way to get it done.

written by M@ \\ tags: Desktop, Edgy, FC6, Fedora, Getting Help, Gnome, Ubuntu

Before I started using Linux I heard about all of the help you couldn’t get on-line, the rumor was that many times when you asked for help, you got the standard response; RTFM (an acronym for read the fine manual – family friendly blog folks). For the record, I have never once received that response, I have many times been given assistance and then a follow-up suggestion to check the man page for further info. Maybe it’s just the distros I’m using, but I’ve had great experiences with forums and IRC. Anyway, that isn’t really the topic here, before you can RTFM, you need to know how.

Reading man pages is easy but it requires a bit of command line interaction. Open up your terminal program (most likely konsole or gnome-terminal) and enter the command:

man shutdown

What this will show you is the man page for the shutdown command. The man page will give you the name, synopsis, description and options for shutdown.

You can scroll through the man pages using page up/page down as well as the up and down arrow keys. When your finished press q to dismiss the page and return to the prompt.

Within the shutdown man page (and many others) you will find a See Also section, this will refer you to other man pages related to the command:

SEE ALSO

fsck(8), init(8), halt(8), poweroff(8), reboot(8)

You can return to the prompt and enter man reboot for more information on that command. Don’t enter the (8) following the command (but if you want to, you would enter it as man 8 reboot). The numbers in parenthesis following the commands indicate the category the command is assigned to (8 is the system administration category). For more information on manual pages visit http://en.wikipedia.org/wiki/Man_page or enter man man at your prompt.

written by \\ tags: Getting Help