Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Child Fund

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Linux Tutorial

· Shells and Utilities
· The Shell
· The Search Path
· Directory Paths
· Shell Variables
· Permissions
· Regular Expressions and Metacharacters
· Quotes
· Pipes and Redirection
· Interpreting the Command
· Different Kinds of Shells
· Command Line Editing
· Functions
· Job Control
· Aliases
· A Few More Constructs
· The C-Shell
· Commonly Used Utilities
· Looking for Files
· Looking Through Files
· Basic Shell Scripting
· Managing Scripts
· Shell Odds and Ends

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 233 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - Shells and Utilities - The C-Shell
  A Few More Constructs ---- Commonly Used Utilities  


The C-Shell

One of the first "new" shells to emerge was the csh or C-Shell. It is so named because much of the syntax it uses is very similar to the C programming language. This isn't to say that this shell is only for C programmers, or programmers in general. Rather, knowing C makes learning the syntax much easier. However, it isn't essential. (Note: The csh syntax is similar to C, so don't get your dander up if it's not exactly the same.)

The csh is normally the shell that users get on many UNIX systems. Every place I ever got a UNIX account, it was automatically assumed that I wanted csh as my shell. When I first started out with UNIX, that was true. In fact, this is true for most users. Because they don't know any other shells, the csh is a good place to start. You might actually have tcsh on your system, but the principles are the same as for csh.

As you login with csh as your shell, the system first looks in the global file /etc/cshrc. Here, the system administrator can define variables or actions that should be taken by every csh user. Next, the system reads two files in your home directory: .login and .cshrc. The .login file normally contains the variables you want to set and the actions you want to occur each time you log in.

In both of these files, setting variables have a syntax that is unique to the csh. This is one major difference between the csh and other shells. It is also a reason why it is not a good idea to give root csh as its default shell. The syntax for csh is

set variable_name=value

whereas for the other two, it is simply

variable=value

Because many of the system commands are Bourne scripts, executing them with csh ends up giving you a lot of syntax errors.

Once the system has processed your .login file, your .cshrc is processed. The .cshrc contains things that you want executed or configured every time you start a csh. At first, I wasn't clear with this concept. If you are logging in with the csh, don't you want to start a csh? Well, yes. However, the reverse is not true. Every time I start a csh, I don't want the system to behave as if I were logging in.

Let's take a look as this for a minute. One of the variables that gets set for you is the SHELL variable. This is the shell you use anytime you do a shell escape from a program. A shell escape is starting a shell as a subprocess of a program. An example of a program that allows a shell escape is vi.

When you do a shell escape, the system starts a shell as a new (child) process of whatever program you are running at the time. As we talked about earlier, once this shell exits, you are back to the original program. Because there is no default, the variable must be set to a shell. If the variable is set to something else, you end up with an error message like the following from vi:

invalid SHELL value: <something_else>

where <something_else> is whatever your SHELL variable is defined as.

If you are running csh and your SHELL variable is set to /bin/csh, every time you do a shell escape, the shell you get is csh. If you have a .cshrc file in your home directory, not only is this started when you log in, but anytime you start a new csh. This can be useful if you want to access personal aliases from inside of subshells.

One advantage that the csh offered over the Bourne Shell is its ability to repeat, and even edit, previous commands. Newer shells also have this ability, but the mechanism is slightly different. Commands are stored in a shell "history list," which, by default, contains the last 20 commands. This is normally defined in your .cshrc file, or you can define them from the command line. The command set

history=100

would change the size of your history list to 100. However, keep in mind that everything you type at the command line is saved in the history file. Even if you mistype something, the shell tosses it into the history file.

What good is the history file? Well, the first thing is that by simply typing "history" with nothing else you get to see the contents of your history file. That way, if you can't remember the exact syntax of a command you typed five minutes ago, you can check your history file.

This is a nice trick, but it goes far beyond that. Each time you issue a command from the csh prompt, the system increments an internal counter that tells the shell how many commands have been input up to that point. By default, the csh often has the prompt set to be a number followed by a %. That number is the current command, which you can use to repeat those previous commands. This is done with an exclamation mark (!), followed by the command number as it appears in the shell history.

For example, if the last part of your shell history looked like this:

21 date 22 vi letter.john 23 ps 24 who

You could edit letter.john again by simply typing in !22. This repeats the command vi letter.john and adds this command to your history file. After you finish editing the file, this portion of the history file would look like

21 date 22 vi letter.john 23 ps 24 who 25 vi letter.john

Another neat trick that's built into this history mechanism is the ability to repeat commands without using the numbers. If you know that sometime within your history you edited a file using vi, you could edit it again by simply typing !vi. This searches backward though the history file until it finds the last time you used vi. If there were no other commands since the last time you used vi, you could also Enter !v.

To redo the last command you entered, you could do so simply by typing in !!.

This history mechanism can also be used to edit previously issued commands. Lets say that instead of typing vi letter.john, we had typed in vi letter.jonh. Maybe we know someone named jonh, but that's not who we meant to address this letter to. So, rather than typing in the whole command, we can edit it. The command we would issue would be !!:s/nh/hn/.

At first, this seems a little confusing. The first part, however, should be clear. The "!!" tells the system to repeat the previous command. The colon (:) tells the shell to expect some editing commands. The "s/nh/hn/" says to substitute for pattern nh the hn. (If you are familiar with vi or sed, you understand this. If not, we get into this syntax in the section on regular expressions and metacharacters.)

What would happen if we had edited a letter to john, done some other work and decided we wanted to edit a letter to chris instead. We could simply type !22:s/john/chris/. Granted, this is actually more keystrokes than if we had typed everything over again. However, you hopefully see the potential for this. Check out the csh man-page for many different tricks for editing previous commands.

In the default .cshrc are two aliases that I found quite useful. These are pushd and popd. These aliases are used to maintain a directory "stack". When you run pushd <dir_name>, your current directory is pushed onto (added to) the stack and you change the directory to <dir_name>. When you use popd, it pops (removes) the top of the directory stack and you change directories to it.

Like other kinds of stacks, this directory stack can be several layers deep. For example, lets say that we are currently in our home directory. A "pushd /bin" makes our current directory /bin with our home directory the top of the stack. A "pushd /etc" brings us to /etc. We do it one more time with pushd /usr/bin, and now we are in /usr/bin. The directory /usr/bin is now the top of the stack.

If we run popd (no argument), /usr/bin is popped from the stack and /etc is our new directory. Another popd, and /bin is popped, and we are now in /bin. One more pop brings me back to the home directory. (In all honesty, I have never used this to do anything more than to switch directories, then jump back to where I was. Even that is a neat trick.)

There is another useful trick built into the csh for changing directories. This is the concept of a directory path. Like the execution search path, the directory path is a set of values that are searched for matches. Rather than searching for commands to execute, the directory path is searched for directories to change into.

The way this works is by setting the cdpath variable. This is done like any other variable in csh. For example, if, as system administrator, we wanted to check up on the various spool directories, we could define cdpath like this:

set cdpath = /usr/spool

Then, we could enter

cd lp

If the shell can't find a subdirectory named lp, it looks in the cdpath variable. Because it is defined as /usr/spool and there is a /usr/spool/lp directory, we jump into /usr/spool/lp. From there, if we type

cd mail

we jump to /usr/spool/mail. We can also set this to be several directories, like this:

set cdpath = ( /usr/spool /usr/lib /etc )

In doing so, each of the three named directories will be searched.

The csh can also make guesses about where you might want to change directories. This is accomplished through the cdspell variable. This is a Boolean variable (true/false) that is set simply by typing

set cdspell

When set, the cdspell variable tells the csh that it should try to guess what is really meant when we misspell a directory name. For example, if we typed

cd /sur/bin (instead of /usr/bin)

the cdspell mechanism attempts to figure out what the correct spelling is. You are then prompted with the name that it guessed as being correct. By typing in anything other than "n" or "N," you are changing into this directory. There are limitations, however. Once it finds what it thinks is a match, it doesn't search any further.

For example, we have three directories, "a," "b," and "c." If we type "cd d," any of the three could be the one we want. The shell will make a guess and choose one, which may or may not be correct.

Note that you may not have the C-Shell on your system. Instead, you might have something called tcsh. The primary difference is that tcsh does command line completion and command line editing.

 Previous Page
A Few More Constructs
  Back to Top
Table of Contents
Next Page 
Commonly Used Utilities


MoreInfo

Test Your Knowledge

User Comments:


You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
  

Looking for a "printer friendly" version?


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial welcomes your suggestions and ideas.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.13 Seconds