Overclock.net banner

1 - 20 of 41 Posts

·
Registered
Joined
·
713 Posts
Discussion Starter · #1 ·
This is just a quick tutorial on how to enhance your command line skills for those that are relatively new to Linux or the Unix world, and in particular, the bash shell.

A long time ago, when I was a Unix/Linux newbie myself, I met an old school emacs/bash dude named Kevin. The guy was one of those freak'n smart dudes that studied and did research in artificial intelligence and cognitive sciences and designed all sorts of software. I was pretty new to the Unix/Linux world and didn't quite "see the light" just yet, but Kev showed me some pretty cool stuff with the bash shell that made me say "wow! I want to be able to do that too!". So, here I am several years later, i figure i'd share it with other new comers too. And this being OCN, I figure there would be some interest in getting all the "performance" one can out of the command line.

Before I got into Linux and Unix, I use to think, "man, why do these people still use the command line? that's so old school when it's so much easier to use a GUI.." Well, the reason is that in many cases, especially if you know what you're doing (that's the key), using the command line can be much faster than pointing and clicking. Think about it; if your fingers are right over a key, how long does it take for you to hit that key, or combination of keys? Now, if you had to move your hand over to your mouse, move the mouse cursor over to some button and click on it, there's a lot more involved there. It requires hand-eye coordination, not to mention if you were clicking on a menu, you'd have to click a couple more times to get to where you want to go. So, the key to getting really fast at working on Linux/Unix is to be able to do as much as possible without having to move your hand away from the keyboard. And if you believe in this methodology, then bash has some really cool features that will turbocharge your command line skills.

Tip #1: just because it's a command line doesn't mean you have to type everything!

The first tip, and in my opinion, the easiest to learn is command line completion, some times also called 'tab' completion. Basically, whenever you are typing a command or a path to a directory or file, bash will help you complete the word you're typing if you hit the 'tab' key. If there are multple possibilities, and bash can't figure out exactly what you were trying to type, you can hit 'tab' twice for it to show you all the possibilities it knows of.

Here's an example, say I want to 'cd' into the directory /etc/sysconfig/network-scripts, this is where network configurations are found in Redhat/Fedora systems. Well, that path is 30 characters long! Instead of
typing all 30 characters, let's see how tab completion can help us. Let's start with:

Code:

Code:
# cd /e
(i've typed 2 characters of the path, now hit 'tab')

Code:

Code:
# cd /etc/
(bash figured out that there's only one directory that starts with 'e', so it automatically completes the 't' and 'c' and '/' for me. but I'm not done yet...)

Code:

Code:
# cd /etc/sy
(i start typing 's' and 'y' for 'sysconfig', and then i hit tab)

Code:

Code:
# cd /etc/sysconfig/
(again, only one directory starts with 'sy', so bash typed the rest for me.)

Code:

Code:
# cd /etc/sysconfig/n
(i start with 'n' for 'network-scripts' and hit tab)

Code:

Code:
# cd /etc/sysconfig/network
(bash helped me complete the word 'network', but it stopped short of finishing it with 'network-scripts' which is where i want to go. let's hit 'tab' twice to see why it didn't complete all the way)

Code:

Code:
# cd /etc/sysconfig/network
networking/network-scripts/
(here, bash is telling me there are two directories that start with the word 'network' and it doesn't know which one i really want. well, i'll give it another hint by typing '-' and hitting tab)

Code:

Code:
# cd /etc/syconfig/network-scripts/
That's exactly what i wanted! So this is what i actually would have typed:

/e <tab> sy <tab> n <tab> - <tab>

That's 10 key strokes that replaced the original 30! For Unix/Linux novices that watch me work on servers, they always ask me at some point, "how do you type so fast?!?!?" ... well, I tell them, "I don't, I let the computer do most of the typing, that's what they are for!"

The bash shell has all sorts of "completion" capabilities, like completing user names, host names, etc. But by far, the 'tab' key is the easiest and most useful.

Tip #2: if you've typed that command once, or something like it, don't type it all over again!

This tip is really about a feature in bash called command recall. The simplest form of this that is often discovered and used by beginners is the "up" arrow key. Open a command shell and type a few commands like 'ls', 'free', 'df', etc. Now hit the "up" arrow key and you'll see that your previously typed command is recalled for you to re-use or modify, should you choose to do so. Consecutive strokes of the "up" arrow key will recall even earlier commands you've typed in reverse history order. Using the "down" arrow key does the opposite and brings you back to later commands you've typed and eventually back to your blank command prompt.

Now, remember what I said about not moving your fingers away from the keyboard? Well, if you go for the "up" or "down" arrow keys, which usually reside to the right of the main alphabet keys, you've just added some latency by having to move your right hand over to the arrow keys and then back to the alphabet keys to continue typing. What a shame to waste such hand movement just to hit an arrow key! Here's how to accomplish the same thing even quicker! : Ctrl-P and Ctrl-N.

Ctrl-P (P for Previous) will recall the previous command. It is basically like using the "up" arrow.

Ctrl-N (N for Next) will recall the next command. It is basically like using the "down" arrow.

Now you can accomplish the same command recall without moving your fingers away from the alphabet keys allowing you to immediately resume your typing with little latency!

Let's do a simple example. Let's say i want to see a list of processes owned by the user "BLinux". So I might use a command like:

Code:

Code:
# ps -ef | grep ^BLinux
... <long listing of proccesses that start with BLinux> ...
Now, let's say i want to know how many processes were listed from the above command. I can accomplish this by doing a "line count" with the command 'wc -l'. But, I don't have to type that command all over again and add the 'wc -l'. I can just hit ctrl-P, followed by "| wc -l"

Code:

Code:
# ps -ef | grep ^BLinux | wc -l
64
This tells me that there are 64 processes being run by user "BLinux". Had I re-typed the whole "ps -ef | grep ^BLinux" part, that would be another 20 characters, on top of the " | wc -l" (8 characters) part. Command recall with ctrl-P just saved me from typing 20 characters and my fingers never left the alphabet keys so I could immediately type the additional pipe ("|") and line count ("wc -l").

Well, ctrl-N and ctrl-P are great, but it is really only useful if you're trying to recall one or two commands back. What if you wanted to recall that command that you typed 300 commands ago? What if you don't even remember how far back you have to go? What if you need that long command you typed yesterday? Bash has another way to recall previously typed commands, so long as they are in your command history buffer. (the default buffer length is usually 1000 entries) The magic key combination is ctrl-R.

When you hit ctrl-R, you get the following prompt:

Code:

Code:
(reverse-i-search)`':
from this point on, you can start typing a pattern or the beginning of a command you previously entered. as you type the pattern, bash will do a reverse search of commands that match the pattern you enter. you can keep typing more of the pattern to narrow down the search, or you can hit ctrl-R again to search further back using the current search pattern. Once you find the command that you are looking for, you can hit 'enter' to execute it, or 'esc' to stop the search and edit the command.

Examples are always useful. Let's say that 3 days ago, I mounted a CIFS windows share and have since umounted it. Today, I want to mount that share again, but not only was it a rather long command, I don't exactly remember the server name, the domain name, or user account that i used. *BUT* I do remember that it is one of the few commands i've typed in recent history that had 'cifs' in it. So, i'll do a ctrl-R reverse search for 'cifs':

Code:

Code:
(reverse-i-search)`cifs': mount -t cifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=BLinux
You can see as soon as i typed 'cifs', it recalled the command i entered several days ago. Now, I can just hit enter and it will immediately run that command. With just 5 key strokes (ctrl-R, 'c', 'i', 'f', 's'), I have recalled a somewhat cumbersome command that is 97 characters long! This Ctrl-R form is probably the most powerful of all the command recall techniques.

Tip #3: Moving around the command line doesn't mean repeated use of the arrow keys!

Let's say that I recall the 'mount' command in the last example of Tip #2. But last time I connected as user 'BLinux', I couldn't access all the files and so this time I want to connect to that CIFS/SMB share as 'Administrator'. Well, I would have to change the user=BLinux part to user=Administrator. So, if after searching for 'cifs' and I hit 'esc', instead of running the command i recalled, i can now edit it and make changes before running it again. When i hit 'esc', i get this:

Code:

Code:
# mount -t [B][c][/B]ifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=BLinux
In the above line, i have put brackets [ ] around the 'c' to point out the location of the cursor. So, if I want to change the user=BLinux to something else, I would have to hit the right arrow key several times, or hold it down and wait for the cursor to move all the way to the end of the command so i can change 'BLinux' to 'Administrator'. That's a lot of arrow key strokes and a pretty long latency... and we know latency is our enemy! Not to mention, we don't want to move our fingers away from the alphabet keys!

Instead, bash gives us very quick ways to move around the command line to edit commands. Here are some of the key combinations that I use the most for cursor movement:

Ctrl-A : move cursor to the beginning of the command line
Ctrl-E : move cursor to the end of the command line
Ctrl-F : move cursor one character forward
Ctrl-B : move cursor one character backward
Alt-F : move cursor one word forward
Alt-B : move cursor one word backward

There are even key combinations to help you delete things faster:

Ctrl-d : delete the character under the cursor
Alt-d : delete the word starting from the cursor
Ctrl-k : delete everything from the cursor to the end of the line (kill the line forward)
Ctrl-u : delete everything from the cursor to the beginning of the line

So, with these in mind, we can use Ctrl-E to go to the end of line, Alt-B to move the cursor one word back, which puts our cursor on top of the 'B' in 'BLinux', and finally we can delete 'BLinux' with Alt-d. Then we can enter 'Administrator' and hit enter.

Using [] to represent our cursor, this is what it would look like:

a. we use ctrl-r to search for 'cifs' and hit 'esc' so that we can edit the command:

Code:

Code:
# mount -t [B][c][/B]ifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=BLinux
b. next, we use ctrl-e to get our cursor to the end of the line:

Code:

Code:
# mount -t cifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=BLinux[B][][/B]
c. next, we use alt-b to move the cursor back one word to the beginning of 'BLinux':

Code:

Code:
# mount -t cifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=[B]Linux
d. next, we delete 'BLinux' with alt-d:

Code:

Code:
# mount -t cifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=[B][][/B]
e. finally, we can enter 'Administrator' and hit 'enter' to run the command:

Code:

Code:
# mount -t cifs //biggie.myhome.net/music /mnt/cifs/music -o domain=myhome.net,user=Administrator[B][][/B]
Notice how we can manipulate the command line without ever having our fingers leave the main alphabet keys which allows us to continue entering commands efficiently without any hand movement delays.

Tip #4: work in multiple directories with stacking

Ever have to make configuration changes in one directory, then have to go back to your home directory, and maybe even have to work in a 3rd directory? If so, do you ever get tired of 'cd' back and forth? Even if you use 'tab' completion or command recall to make your 'cd <path>' commands relatively quick, it can get annoying.

To make life easier in this situation, bash has a feature called 'directory stacking'. It's very simple, and there are only three commands you really need to know to use this. But, before I get into that, since not everyone will be familiar with the concept of a 'stacks', which is also known as a LIFO (Last In, First Out), let me start by explaining the 'stack' concept.

You can think of a 'stack' like a stack of dishes. When you put a new dish onto the stack, that dish becomes the top of the stack. When you want to remove a dish from the stack, you have to remove the top dish first (hence: last in, first out) before you can get to the dishes underneath it. If you wanted to get at a dish that is somewhere in the middle of the stack, you have to remove all the dishes on top of that dish first before you can get to it.

Now, instead of 'dishes', imagine that you are stacking up directories. Here are the commands you need to know to use directory stacking:

dirs : list your directory stack
pushd : push (add) a new directory onto the stack
popd : pop (remove) a directory from the stack

Here's an example. Let's say I want to be able to work in my home directory, the /etc directory, and the temp directory /var/tmp. We start out in my home directory, /home/BLinux, and i'll also list my stack with 'dirs':

Code:

Code:
# pwd
/home/BLinux
# dirs
~
Now, let me add /etc to my stack with 'pushd':

Code:

Code:
# pushd /etc
/etc ~
# pwd
/etc
You'll see that we've moved into /etc, it is now the top of the stack (left most entry in the listing), and the command automatically lists my stack as "/etc ~" which is /etc and ~ (my home directory). Next, let me also add /var/tmp to the stack too:

Code:

Code:
# pushd /var/tmp
/var/tmp /etc ~
# pwd
/var/tmp
Now, i'm in /var/tmp, which is the top of the stack, with '/etc' underneath it, and '~' at the very bottom. Now that i have all 3 directories in my stack, I can move around to the different directories with the 'pushd' command. Lets say I want to swap the top directory with the one underneath it, i simply use 'pushd' with no arguments:

Code:

Code:
# pushd
/etc /var/tmp ~
# pwd
/etc
Now, what if I want to jump two directories down my stack to my home directory (~)? Easy, just tell 'pushd' that you want to go to jump 2 directories down:

Code:

Code:
# pushd +2
~ /etc /var/tmp
# pwd
/home/BLinux
Next, let's say that I don't need my home directory (~) in my stack anymore. I can remove it from the stack with the 'popd' command:

Code:

Code:
# popd
/etc /var/tmp
# pwd
/etc
You can see that the home directory entry (~) has been removed, and I've ended up on the next directory in the stack, which is /etc.

In this way, you can stack up all the directories you want to work in, and be able to move between them with relatively simple commands instead of having to type long path names.

Tip #5: just because you have one command prompt doesn't mean you can only run one program at a time.

This is about a feature called job control. For many who are just learning how to get comfortable on the command line in Unix/Linux, it is often assumed that you can only run one program at a time and you have to wait for the current running program to complete and return your prompt before you can execute the next command. However, the truth is that you can run as many commands as you want from a single command prompt. Here's how:

background jobs: if you append '&' to the end of a command, that command will run in the background and your command prompt will return to you immediately for you to issue the next command even if the 1st command is still running.

For example, let's say you want to delete a directory with a million files. Normally, this operation might take several minutes, but you don't want to sit around waiting for it to complete. So, you run the program in the background like this:

Code:

Code:
# rm -f /path/to/one/million/files/* &
# 
# jobs
[1]+ Running         rm -f /path/to/one/million/files/* &
#
As you can see, the command prompt returns immediately. And when i run 'jobs' it shows that the 'rm' command is still running (in the background). So, now you can run programs in the background and not be held up by them. This is really useful for programs that might take a long time to execute like compressing a large file. It's also good to know about the 'jobs' command, as we'll use it some more later on.

Now, what if we didn't initially know that a certain command was going to take a long time and didn't run it with '&' appended? You can still put a program into the background even if you didn't initially do so. First, you have to send a STOP signal to the current program and get back to the prompt. This is done by hitting Ctrl-Z. When you hit Ctrl-Z, this stops the current program (it is frozen, no longer running) and returns you back to the prompt. Next, since we don't want to freeze the program we were just running, we just want it to continue running in the background, you use the 'bg' command. The 'bg' command will unfreeze the program and continue running it in the background.

Let's look at our compression example. Let's say we started compressing a large file without knowing that it was a really large file. We'll use Ctrl-Z to stop the program can get back to our command prompt:

Code:

Code:
# bzip2 -c9 OneLargeFile > OneLargeFile.bz2 (it's taking too long! hit Ctrl-Z)
^Z
[1]+  Stopped          bzip2 -c9 OneLargeFile > OneLargeFile.bz2
#
As you can see, the bzip2 program is stopped. Let's make it continue in the background with 'bg':

Code:

Code:
# bg
[1]+ bzip2 -c9 OneLargeFile > OneLargeFile.bz2 &
#
# jobs
[1]+  Running           bzip2 -c9 OneLargeFile > OneLargeFile.bz2 &
#
You can see that the bzip2 is now running in the background. But wait, didn't we say we could run "as many commands" as we want from one command prompt? Yes we can:

Code:

Code:
# bzip2 -c9 OneLargeFile > SecondLargeFile.bz2 &
# jobs
[1]- Running            bzip2 -c9 OneLargeFile > OneLargeFile.bz2 &
[2]+ Running            bzip2 -c9 OneLargeFile > SecondLargeFile.bz2 &
#
As you can see, we now have two programs running at the same time, and I have my prompt back to run others. We now know how to run several programs in the background, but what if we want to also be able to interact with more than one program at a time? When you send a program to the background, you can't really interact with it anymore. The way around this is the 'fg' command, or foreground command.

Here's an example; let's say you're downloading some files via FTP using the standard ftp client, meanwhile, you also want to take notes of what you're doing in a personal log file called personal.log. You're going to have to interact with the ftp program, but maybe while it is downloading you want to write entries in your personal log.

We start this example by opening our personal.log in vi. After making our first log entry, we freeze vi to start our FTP session.

Code:

Code:
# vi personal.log (after 1st entry, we hit Ctrl-Z to freeze and break out)
[1]+ Stopped            vim personal.log
# ftp download.fedora.redhat.com
After we login to the FTP site and start downloading a file, say an ISO image of Fedora 11, we can return to our command prompt:

Code:

Code:
ftp> cd pub/linux/fedora/releases/11/Fedora/x86_64/iso
250 Directory successfully changed.
ftp> get Fedora-11-x86_64-DVD.iso
150 Opening BINARY mode data connection for Fedora-11-x86_64-DVD.iso (4268124160 bytes).
^Z
[2]+ Stopped             ftp download.fedora.redhat.com
# bg %2
[2]+ ftp download.fedora.redhat.com &
# jobs
[1]- Stopped             vim personal.log
[2]+ Running             ftp download.fedora.redhat.com
#
In the above, we started a download of Fedora 11, but we didn't want to sit around and wait, so we froze the FTP program with Ctrl-Z. But we don't want to stop the download, so we must let the program continue running in the background. We accomplish this with 'bg %2'. The %2 here designates job #2, which is the ftp program, where as job #1 is our vi session editing personal.log.

Now, let's say while the ftp download is happening, I want to write a few more entries in my personal log, which is already opened in the vi session i started at the beginning. We know the vi session is job #1 (the 'jobs' command tells us so), so we can bring that job back into the foreground with 'fg %1':

Code:

Code:
# jobs
[1]- Stopped             vim personal.log
[2]+ Running             ftp download.fedora.redhat.com
# fg %1
(now, we're in our 'vi' session and we edit our log file, and eventually breaks back out with Ctrl-Z)
vim personal.log

[1]+ Stopped             vim personal.log
#
Let's say we want to be back in our FTP program now, we can do that by foregrounding the FTP job:

Code:

Code:
# jobs
[1]+ Stopped             vim personal.log
[2]- Running             ftp download.fedora.redhat.com
# fg %2
ftp download.fedora.redhat.com (it appears the download is still going, we break out again with Ctrl-Z)
^Z
[2]+ Stopped             ftp download.fedora.redhat.com
# bg
[2]+ ftp download.fedora.redhat.com &
#
So, in this way, we can run many programs, freeze them (Ctrl-Z), run them in the background (bg), or recall them into the foreground again (fg) so long as we can reference their job numbers, which is displayed when we run 'jobs'.

It is indeed possible to be very productive on a single command prompt, while download files in the background and doing other things like compressing files and writing a journal log.

TIP #6: install some pre-programmed completion customizations from "bash-completion"

I should have added this before but working in the server world, I'm not always allowed to install whatever i want on my client's machines so I forgot about this. The 'bash-completion' package provides a bunch of pre-programmed completion rules so that bash automatically recognizes what should follow certain commands. It covers a LOT of stuff and I've found it to be very useful where I am able to use it. It can be found here:

http://www.caliban.org/bash/

Well, that's it for now. Once you master these skills, i can promise you that you'll be able to work faster on the command line than you ever will moving a mouse cursor around and clicking buttons and menus. Just remember, the key is to learn how to keep your fingers on top of the alphabet keys as much as possible without having to move your hand around. Once you've mastered doing things quickly on the command line, you'll actually start getting annoyed when you *have to* use the mouse for certain things.
 

·
Premium Member
Joined
·
4,616 Posts
Nice guide. The tab completion is especially nice.
 

·
Registered
Joined
·
713 Posts
Discussion Starter · #4 ·
Quote:


Originally Posted by GodofGrunts
View Post

Nice guide. The tab completion is especially nice.


Quote:


Originally Posted by equimen
View Post

Very well explained guide for Linux noobs!

Thanks guys for the thumbs up! There was actually more I wanted to write about, but ran out of steam. I may follow up and add more later. If you guys have any suggestions/feedback, i'm open to hearing them too!
 

·
Registered
Joined
·
1,698 Posts
Good stuff... I would also say one of my most used keys on the command line is the up arrow in linux.... it remembers all those commands you typed on the command line...not just during your current session... even after you shut down the computer and restart, log on and bring up the terminal... up arrow and those commands are still there!
 

·
Premium Member
Joined
·
10,351 Posts
Wow, I didn't realize that the tab button could be used to complete arguments as well. I thought it was only for commands themselves.
 

·
Premium Member
Joined
·
4,616 Posts
Quote:

Originally Posted by The Hundred Gunner View Post
Wow, I didn't realize that the tab button could be used to complete arguments as well. I thought it was only for commands themselves.
O.O How have you lived?! Everything would take FOREVER.
 

·
Registered
Joined
·
713 Posts
Discussion Starter · #10 ·
Thanks guys! I've added a 4th tip about directory stacking.

Quote:

Originally Posted by MrAMD_Fan View Post
Good stuff... I would also say one of my most used keys on the command line is the up arrow in linux.... it remembers all those commands you typed on the command line...not just during your current session... even after you shut down the computer and restart, log on and bring up the terminal... up arrow and those commands are still there!
Yup, the history buffer is written to a file in your home directory named .bash_history when you exit the bash shell. When you fire up the shell, it reads in that file so your command history is retained. This is a very useful feature, but also a potential security problem, so beware. For example, if you type a command that includes a password in the argument list, that password gets recorded in your history file. So, someone who gets access to that file can potentially find your passwords revealed. If you want to make sure that such commands never get written to your history file, you can symbolically link your history file to /dev/null like:

# ln -s /dev/null ~/.bash_history

Of course, if you do this, your history buffer is not retained between bash shell invocations.
 

·
Registered
Joined
·
1,698 Posts
Quote:

Originally Posted by BLinux View Post
Thanks guys! I've added a 4th tip about directory stacking.

Yup, the history buffer is written to a file in your home directory named .bash_history when you exit the bash shell. When you fire up the shell, it reads in that file so your command history is retained. This is a very useful feature, but also a potential security problem, so beware. For example, if you type a command that includes a password in the argument list, that password gets recorded in your history file. So, someone who gets access to that file can potentially find your passwords revealed. If you want to make sure that such commands never get written to your history file, you can symbolically link your history file to /dev/null like:

# ln -s /dev/null ~/.bash_history

Of course, if you do this, your history buffer is not retained between bash shell invocations.
Ah, yes... that is a good point... Nice tip! Nice to have linux people on OCN... I switched my main PC to linux about a year and a half ago and it has been great for me. I have virtual box running XP for my stuff i couldn't do in linux (which ain't much!). Your sig rig looks like a server... 48gb ram would be good for virtualization.....
EDIT: I see a PERC 6/I in there perhaps a dell server???
 

·
Registered
Joined
·
713 Posts
Discussion Starter · #12 ·
Quote:


Originally Posted by MrAMD_Fan
View Post

Ah, yes... that is a good point... Nice tip! Nice to have linux people on OCN... I switched my main PC to linux about a year and a half ago and it has been great for me. I have virtual box running XP for my stuff i couldn't do in linux (which ain't much!). Your sig rig looks like a server... 48gb ram would be good for virtualization.....
EDIT: I see a PERC 6/I in there perhaps a dell server???

Yeah, old school Linux/Unix n3rd here... besides Linux, I have a few Sun Microsystems (UltraSPARC) Solaris machines, a SGI IRIX machine (MIPS R4400), and a DEC Alpha (21164a).

My sig rig does run virtual machines, one of which is my XP desktop vm for using things like Outlook (for work). I have about half dozen other virtual machines for running different Linux distros. It's a Dell PE2900-III.

Although it is generally easier to run Windows stuff in a VM, I have had some success running some apps under WINE.
 

·
Premium Member
Joined
·
4,616 Posts
Quote:


Originally Posted by BLinux
View Post

My sig rig does run virtual machines, one of which is my XP desktop vm for using things like Outlook (for work).

Can you not use Thunderbird for mail?
 

·
Registered
Joined
·
713 Posts
Discussion Starter · #14 ·
Quote:


Originally Posted by GodofGrunts
View Post

Can you not use Thunderbird for mail?

Nope, unfortunately there is no mail client in the Linux world that is as comprehensive as Outlook. It's not just IMAP/POP3 stuff, being able to share address books, calenders, tasks on Exchange is invaluable to many businesses and so far, the Linux world hasn't been able to offer something that can truly replace it, at least not something that is completely free.

I have heard that the latest Evolution mail client can support the MS Exchange protocols, but I don't know to what extent and what features are supported. I plan to try it out and see if it becomes a suitable replacement.

Sadly, the Linux world is still far behind the Windows world as far as critical desktop business apps... even Thunderbird isn't as good a mail client as Outlook, not counting the Exchange specific features. As much as I rather not use MS apps, even something like Open Office just doesn't seem as "refined" as the latest MS Office... I think the FOSS world still has a lot of catching up to do in this area.
 

·
Registered
Joined
·
1,698 Posts
Quote:


Originally Posted by GodofGrunts
View Post

Can you not use Thunderbird for mail?

I use thunderbird for mail but, not for work.... i have a laptop for work with XP and Outlook. We just switched to Exchange 2k8 at work. Thunderbird is good for pop mail.... I have used it for several years... as well as open office....
EDIT: I know that wasn't directed to me.... just buttin' in....
 

·
Registered
Joined
·
1,560 Posts
Quote:


Originally Posted by BLinux
View Post

Yeah, old school Linux/Unix n3rd here... besides Linux, I have a few Sun Microsystems (UltraSPARC) Solaris machines, a SGI IRIX machine (MIPS R4400), and a DEC Alpha (21164a).

Damn dude, you are a Unix geek!
 

·
Registered
Joined
·
713 Posts
Discussion Starter · #17 ·
Quote:


Originally Posted by thiussat
View Post

Damn dude, you are a Unix geek!


Yes sir!
Ultimately, even though a lot of the Unix hardware is becoming more and more obsolete, they certainly are more interesting than PC hardware. I use to even have a PA-RISC machine for HP-UX, but I sold that off a while ago.

Okay! I've added a 5th tip about job control... hopefully another useful tip. I think that covers most of the useful daily command prompt skills. Is there anything else I should cover?
 

·
Registered
Joined
·
296 Posts
+rep

This should be in the Essential Reading for Linux Lovers thread.
 

·
10 year OCN Vet
Joined
·
3,422 Posts
Quote:


Originally Posted by BLinux
View Post

wow, i just got repped for this 1 yr old thread... hope you guys are finding it helpful...


I'm not surprised. Your foo is pretty kung. There are other threads about command line but yours is more methodical than most. Few get deep into commands and I don;t know how people get along without cat, awk, grep and sed in addition to those you've pointed out. I've been doing Linux since 1996 and never used Ctrl-P so even those of us who are not tab key impaired can possibly learn something.

OT
Geez the DEC Alpha! What a great blast from the past. I'm betting few in here know that
those boys had a 500MHz CPU with 4 instruction per clock when Intel could barely make 200 MHz at 2 ipc and the DEC boys did it without a fan! Then the capper is that many of the Alpha team were hired away by AMD and were responsible for the whole Athlon series and especially eclipsing Intel with 64bit. What expansion slots does it have, PCI-X?
 
1 - 20 of 41 Posts
Top