Shell tutorial part 1

From LXF Wiki

(Difference between revisions)
Revision as of 10:11, 28 May 2008
Towy71 (Talk | contribs)

← Go to previous diff
Revision as of 10:48, 28 May 2008
Towy71 (Talk | contribs)

Go to next diff →
Line 1: Line 1:
- 
== LINUX SHELL PROGRAMMING == == LINUX SHELL PROGRAMMING ==
-Shell secrets+ 
 +== Shell secrets ==
 + 
 + 
PART 1 ''Marco Fioretti'' explains how to unleash all the power of the command line. PART 1 ''Marco Fioretti'' explains how to unleash all the power of the command line.
 +
 +The Linux platform is becoming a stronger desktop solution day by day, and part of the reason for this is the commitment by distribution authors to provide an exclusively graphical user interface, from installation to upgrade. We shouldn’t forget, though, that the command line interface still exists. It may not be as pretty as a GUI but this alternative interface has flexibility, and there are many cases where it can save you a lot of time. For example, you can use the command line to save and rerun long sequences of commands, or create new ones to be executed en masse.
 +The great thing about the command line is that you don’t have to be a guru to use it. Even end users can use it, and will find it useful and even fun to write commands this way.
 +And why take the trouble? Well, unlike in a GUI, where you can only click the buttons that somebody else thought were needed, you can create your own commands and tailor your system. For example, have you ever wanted to issue multiple commands with as little clicking as possible? If so, welcome to the shell prompt. Or consider the boot process, which involves a chain of text commands executed in a well-defined order and can be greatly customised if you know how.
 +In fact, there’s nothing to stop you from getting the best of both worlds. Once a script works on the command line, it can be easily bound to a GUI’s desktop icon or menu entry. Then in the event of an emergency you can call on your command line knowledge to stay in operation. What about disaster recovery with a GUI - where do you point and click if you need to reinstall the X server?
 +
 +
 +== Inside the shell ==
 +
 +
 +All command-line typing happens inside what’s known in Unixland as a shell. This is both a programming language and a command interpreter, providing an interface to the operating system. Every shell has control flow structures, manipulates variables and can be modified to suit the environment in which programs run - but often they do this in slightly different ways.
 +There are hundreds of shells available for Linux, but you might only have a handful of them installed. To find which ones are installed in your system, type the following command:
 + $ cat /etc/shells
 +Bash (Bourne-Again Shell, an adaptation of the original Bourne shell originally written by Stephen Bourne at AT&T) is the most common choice on Linux systems. Another popular one is csh (C Shell), with a syntax more similar to the C programming language. tcsh is an enhanced, backward-compatible version of csh. The reason why there is more than one solution for (apparently) the same problem is the usual one: different shells may have different licences, and each one is optimised for slightly different uses. Find out more online at http://consult.cern.ch/writeup/shellchoice/main.ps, an in-depth discussion of these and other shell programs that was written before bash claimed dominance.
 +Programs written in a shell language, or any other interpreted one, are normally called scripts. They are just plain text files containing sequences of commands. Scripts are loaded and executed by the interpreter line by line, just as if you were typing the same sequence of instructions at the prompt. More explicitly, there isn’t anything that you can place in a shell program that you can’t type at the shell prompt, and vice versa.
 +Are scripts better or worse than normal, binary-compiled programs? No, just different. Binary programs are faster but take programs? No, just different. Binary programs are faster but take much more time to develop and test. Scripts are much quicker to write but normally run much slower. What is important, and to write but normally run much slower. What is important, and should be evaluated case by case, is that the total time spent writing and running the program is minimised. In practice, shell scripts are usually the best match for the custom programming skills and needs of home and small-office Linux users.
 +Programs and keywords
 +Software programs are specific binary files physically stored on the hard disk. As a command line-based programming language, every shell can launch them directly. Shells also have, however, a set of built-in keywords, or commands, not corresponding to any actual program. This can cause confusion

Revision as of 10:48, 28 May 2008

LINUX SHELL PROGRAMMING


Shell secrets


PART 1 Marco Fioretti explains how to unleash all the power of the command line.

The Linux platform is becoming a stronger desktop solution day by day, and part of the reason for this is the commitment by distribution authors to provide an exclusively graphical user interface, from installation to upgrade. We shouldn’t forget, though, that the command line interface still exists. It may not be as pretty as a GUI but this alternative interface has flexibility, and there are many cases where it can save you a lot of time. For example, you can use the command line to save and rerun long sequences of commands, or create new ones to be executed en masse. The great thing about the command line is that you don’t have to be a guru to use it. Even end users can use it, and will find it useful and even fun to write commands this way. And why take the trouble? Well, unlike in a GUI, where you can only click the buttons that somebody else thought were needed, you can create your own commands and tailor your system. For example, have you ever wanted to issue multiple commands with as little clicking as possible? If so, welcome to the shell prompt. Or consider the boot process, which involves a chain of text commands executed in a well-defined order and can be greatly customised if you know how. In fact, there’s nothing to stop you from getting the best of both worlds. Once a script works on the command line, it can be easily bound to a GUI’s desktop icon or menu entry. Then in the event of an emergency you can call on your command line knowledge to stay in operation. What about disaster recovery with a GUI - where do you point and click if you need to reinstall the X server?


Inside the shell


All command-line typing happens inside what’s known in Unixland as a shell. This is both a programming language and a command interpreter, providing an interface to the operating system. Every shell has control flow structures, manipulates variables and can be modified to suit the environment in which programs run - but often they do this in slightly different ways. There are hundreds of shells available for Linux, but you might only have a handful of them installed. To find which ones are installed in your system, type the following command:

$ cat /etc/shells

Bash (Bourne-Again Shell, an adaptation of the original Bourne shell originally written by Stephen Bourne at AT&T) is the most common choice on Linux systems. Another popular one is csh (C Shell), with a syntax more similar to the C programming language. tcsh is an enhanced, backward-compatible version of csh. The reason why there is more than one solution for (apparently) the same problem is the usual one: different shells may have different licences, and each one is optimised for slightly different uses. Find out more online at http://consult.cern.ch/writeup/shellchoice/main.ps, an in-depth discussion of these and other shell programs that was written before bash claimed dominance. Programs written in a shell language, or any other interpreted one, are normally called scripts. They are just plain text files containing sequences of commands. Scripts are loaded and executed by the interpreter line by line, just as if you were typing the same sequence of instructions at the prompt. More explicitly, there isn’t anything that you can place in a shell program that you can’t type at the shell prompt, and vice versa. Are scripts better or worse than normal, binary-compiled programs? No, just different. Binary programs are faster but take programs? No, just different. Binary programs are faster but take much more time to develop and test. Scripts are much quicker to write but normally run much slower. What is important, and to write but normally run much slower. What is important, and should be evaluated case by case, is that the total time spent writing and running the program is minimised. In practice, shell scripts are usually the best match for the custom programming skills and needs of home and small-office Linux users. Programs and keywords Software programs are specific binary files physically stored on the hard disk. As a command line-based programming language, every shell can launch them directly. Shells also have, however, a set of built-in keywords, or commands, not corresponding to any actual program. This can cause confusion