LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Articles > Technical
User Name
Password

Notices


By stomfi at 2006-02-11 18:06
Linux Power Tools for End Users. Simple Shell Scripting & GUI interfacing for Desktop Users. by Stomfi © 2005

Part 1 – Introduction to the Shell and GUI Magic

Introduction

Amongst all the hype about whether Linux or Windows or Mac is the better desktop, the tools that make each one powerful to users in their own right are often overlooked.

For some power users, it is not unusual to find 2 or 3 desktops on the one desk or sometimes in a dual boot configuration, but even so, the power user tools of a Linux system are often not noticed mainly because they are not part of the GUI and thought to be in the domain of administrators.

Nothing could be further from the truth. The Linux power tools, operated from the command line, were originally designed to be used by the ordinary user as well as administrators.

Many of the tools have nothing to do with administration, being focused on the type of information processing tasks that an ordinary desktop user would be likely to perform. On top of that, certain tools allow the user to completely automate quite complex tasks, without any future hands on input or control.

Back in the last century many women end users found that using the UNIX tools was really as easy as writing out event orders for a parties, and managing a household, so I hope many of you read and enjoy this series. And everyone with an artistic bent can enjoy the first GUI project introduced in part 2 and described in part 5.

This series is going to bring you, the end user, Linux power tools tutorials, using simple scripting methods, practical explicit working examples, and an easy to use GUI interface tool to turn your shell scripts into something you can point and click in the windowing environment.

The GUI Interface Tool

The GUI tool is called Runtime Revolution and works on Linux, the MAC and Windows. It is available from www.runrev.com where you can also find tutorials for using it. When you have built the interface, it is packaged with the Revolution engine and the result can be freely distributed to anyone who wants to use your package. The engine takes up about 2MBytes, but several interfaces can be combined, with a suitable menu, into the one package, saving space on your hard drive as well as in RAM. I am using version 2.2.1 for these tutorials and you may find this version either for free on a magazine cover CD or as a trial licence from RunRev.

The RunRev scripts shown in these tutorials will work on later versions of this great end user tool. RunRev TranScripts are mainly concerned with building the GUI part of each project, which involves putting values into variables, running filters, and making events happen on or off screen. A lot of events start information processing by external Linux shell scripts, which use a similar language to TranScript.

The Linux Shell Tools

The Linux shell is the environment where these tools reside, and is designed to be simple and easy to use and understand. To keep things really simple for the user, the makers of the tools stick to a strict plan where each tool does only one thing, but does it well with most, if not all, possible options. They also supply mechanisms to seamlessly join tools to perform larger tasks and, generally make the tools work in a similar fashion, so that learning how to use one means that the use of others will be familiar.

Back in the last century, clerks, secretaries, executives, engineers and scientists learned how to use the shell to automate their day to day and repetitious tasks so that they could spend time doing creative and productive work. There is absolutely no practical reason, why the same types of users can't learn these tools today, and by using equally simple easy to understand interfacing tools, can't modernise their efforts to add them to the GUI desktop.

Once you start using a new set of tools, you will think of other things you can do with them. These tools are so simple and join together so easily, that it doesn't take much hair pulling and memory cells to get something working that you can be proud of every time you use it or see it.

Many administrators promulgate the idea that the creation of computer solutions is theirs and theirs alone, and that you need to be licensed, certified and a member of the IT section before you can use the shell tools to develop your own solutions.

The reality is that anyone who can type can learn to use shell tools. The Linux shell is not a formal language, it is unstructured on purpose because people without programming training tend to think in unstructured ways. This often leads to unique solutions that would not be thought up, if people were all thinking along the same formal paths.

Because the shell is unstructured and made up of small tools it is very easy to apply to solutions which can be broken down into small steps and typed into a script.

The things to keep in your mind when learning the shell is that it is an inexpensive and easy problem solving tool which can increase your productivity by a very large amount with very little comparable effort. And the amount of remembered knowledge you need, is really quite small, just the basics, how they can be used, how to find the one you want and where to find help.

Those in the front line know that in-house solutions are always more productive and to the point, whereas application based solutions tend to make organisations follow the same pattern of operations as every other business, negating competitive advantages. It's a fact that the bottom-on-seat application based strategy of Microsoft, creates a lot of extra employment, computer sales, and support infrastructure, but many businesses can't afford this apparent waste any more, especially when there are known cost benefits in using cheaper, more productive, less employment intensive ways of utilising computing and human resources, like shell empowered end users.

If all desktop users in an organisation understand the basics of how to use shell solution tools, just like they know word processing, spreadsheets or databases, then using and supporting Linux shell scripts becomes part of normal operations, and has the added benefit of giving back to the business those operational methods and productivities that make it unique from any other.

As with any set of tools, there are easy and hard ways of learning and using them. These articles only show you the easy ways. You can get more and more sophisticated as you progress, but the basic ways the articles set out are proven to work. Anyone who uses these article to learn, should take about 3 months to be up to speed.

A look at the GUI project

Before getting down to the basics, you might like to know what a RunRev GUI/shell project looks like screen. The project is a storyboard for laying out a sequence of picture thumbnails and sounds, for moving, removing, editing and animating them. Picture Editing is done by default with Tuxpaint or the GIMP, and sound editing by another RunRev GUI interface suitable for kids or Audacity.

As you learn how to develop this project, you will think up other features this project should have. Like a preferences menu item to add your own media applications, and other settings. Adding your own features like this is very easy with Runtime Revolution. You can completely change my basic looking interface and really make it your project.

The story board:
[img=640x480]http://images.linuxquestions.org/articles/storyboard1.png[/img]
A list of the shell scripts that make everything work, and the file tree you will build to store the components:


This project is used in a much larger one called 'SCOOL where members of a group compete by creating presentations, so a story board is a useful tool for them to have. You can get 'SCOOL from http://www.stomfi.bigpondhosting.com


For those of you who can't get hold of Runtime Revolution, I shall post the SB runtime file when we get into the project. All you will have to do are the shell scripts and the project tree.

First Steps

Shell Consoles

To start using the shell you need a shell console. This is sometimes called a terminal. There will be at least one kind in the Linux menu. On the SUSE menu it is under System in the Terminal selections. The one I like is the KDE Konsole, as it has a Session menu where others can be started and tabbed into. There is usually one called Xterm which is just the same, except it doesn't have a tabbed interface and you may have to start more than one, especially if you are like me and need to look at the on-line documentation to remember how to use a tool.

Having more than one console open is also very handy for testing that a command works as expected before inclusion in a script

When the console starts, it presents the user with a blank screen with what is called a prompt on the first line. The prompt is waiting for a command. The console itself is also a shell tool that interprets and runs other commands. The interpreter used in these articles is the one called bash. Bash stands for Bourne Again Shell, after the inventor of the original UNIX shell but with many additional features.

Regular and Tabbed Consoles:


Five things you need to know about the Shell.

Commands and Shell Commands


Many commands are programs. Any program including all the ones which are started from the menu can have their name typed after the prompt and activated by pressing the Enter key.

If you have the Mozilla Firefox browser on your system you can type firefox and press Enter and it should start. The console prompt will not reappear for another command until after you quit firefox.

Shell Commands are either non GUI programs, which usually return any output to the console, or controlling mechanisms like conditions, loops or assignments. I use the term “mechanisms” because what we are doing when we tell the computer what to do, is called “information engineering”.

A simple command you can try is “ls” which stands for “list the contents of a folder”. Most Linux shell commands are abbreviated like this. The reason was that computers used to communicate very slowly and less typing meant a faster response. Shell users got familiar to this shorthand way of giving commands, and found it a lot easier to remember these funny names than more meaningful English ones, so the names have carried on down the years.

Shell Command arguments, options and redirection.

Arguments


You can see the names of many of the shell commands with the command “ls /bin”. In this case the command means “list the contents of the folder /bin”. The /bin part is called an argument to the command. The way the command is typed is called the syntax, which in this example contains the command name, a space, and the argument. The ls command can have more than one argument each separated by a space. Like “ls /bin /usr/bin” to see a lot more commands, each folder contents listed in the order it was typed.

Options

Options are given to a command to change it's behaviour. Many commands like our example “ls” have a default behaviour, but some need to be given options before they will work. To change the behaviour of the ls command to make it give a long display showing the type, owner, permission, size, date etc, give the command “ls -l” to see your current folder in this manner. Options are usually given with a single letter. The syntax of typing an option is normally to precede the option with a dash or minus symbol. Like arguments, several options can be given for the same command and can be concatenated without giving a space and separate dash for each one. Thus ls -la will list in long format all the files in the folder including those normally hidden. The shell syntax for options is that they are typed directly before the arguments they are affecting.

Like all things in life there are exceptions to the rule, which is why you see the words usually and normally in the text. These exceptions will be explained as they occur in the article.

Redirections

Instead of having the output of a command go to the console, you may wish to save it in a file for later use. This is done with a redirection operator. There are two for sending the output to a file, one overwrites or creates a file, the other appends to or creates a file. To send the output of the ls /bin command to a file, you can type ls /bin > binlist.txt. To append the output of /usr/bin to this file you can type ls /usr/bin >> binlist.txt. Notice that the syntax includes the usual spaces.

Some commands can also have their input redirected. The general operator for this is < and in some special cases <<.

Escaping Meaning by Quoting

Sometimes you may want to remove the special meaning of symbols that the shell interprets. For example the shell interprets the $ symbol as meaning “ the value of the right hand concatenated token or word”.

To escape its special meaning and use it in its literal form, the shell supplies the backslash as the escape character \.

Thus \$AUD10 would be seen by the shell as $AUD10. (Ten Dollars Australian). Whereas $AUD10 would be seen as a blank string or number. (Unless you had put a value into AUD10 by typing something like AUD10=”Ten Dollars Australian”, then it would be seen as that.)

If you want to preserve the literal meaning of a whole string of characters, enclosing the string in single quotes does this, although a single quote, even one escaped with a backslash, cannot appear within the string.

Enclosing a string in double quotes preserves the literal value of all characters within the quotes except for $, back quote, and the backslash when it is followed by one of $, back quote. back slash or the newline. The symbols * and @ also have special meanings inside double quotes so are to be avoided unless needed for their special meanings which are explained later.

In the example above, the double quotes enclose the literal meaning of Ten Dollars Australian including the spaces which would normally be seen by the shell interpreter to mean it should process the next word as another command or statement.

Things to know about writing shell scripts

Writing Scripts

Text Editors


Before you can type commands into a script file, you need to know how to use a text editor. Text editors save files as plain text without any formatting or special characters, which is how the shell interpreter expects to read them.

There is usually a text editor in the GUI menu, sometimes to be found under Utilities, which you can use. There are also shell editors, the most famous of which is vi the visual editor. Vi is very powerful and offers the shell script writer many handy functions, including the ability to test the script without leaving the editor.

By learning the substitution commands in vi, the user also learns about regular expressions. which are patterns which include wild cards and other substitution constructs which you use a lot in shell scripts. Vi is a bit different from the GUI text editors as it has an insert mode where typing is done, and a command mode where editing is done.

Starting vi in a console without an argument brings up a help menu for learning how to use it. It can take a bit of getting used to for someone familiar with a word processor, but it is optimised for writing shell scripts so can be a great help to those starting out on this journey.

In any case, any text editor will do the job, so the most important thing is to choose one that suits your own style of thinking.

Vi and GUI Text Editors:


Shell Comments

Putting comments in scripts is a really good idea as they are used to explain how and what you are doing, so that you can refer back to them for help and even use the relevant command lines again in another script.

Comments are preceded on a line by the # comment marker symbol. This can appear at the beginning of a line, or after some script commands, but not in the middle of a script line, as once the shell interpreter sees the # it treats everything after it to the end of the line as a comment.

If you have a multi line comment, you must start each line with a #.

There are times when you might want to use the # symbol in a shell command for a special purpose, and the command will usually recognise this case and wont treat it as a comment marker. You can also escape its special meaning with the backslash.

Summing up so far.

All the basic features of the shell, syntax and script creation tools have been described in a simple fashion for ordinary users to understand. There are other useful features of the shell and its tools which will be described as you begin to use them in scripts. These extras will make your shell scripts even more powerful.

In the next article you will learn about command construction and how to plan a practical example which can be used as a basis for real programs at work.

End of Part 1


BOXOUTS

Other Shells

Reusing Commands with the History List

History Operator Short Cuts

Tab key Short Cuts


BOXOUT 1
Other Shells

Linux offers a choice of shells you can use. Each one has different features and syntax. Beside the bash shell used in the article and often the default Linux shell, there is csh invented at Berkeley University with a syntax similar to the C programming language and tcsh, an enhanced version. Sash is a stand alone shell with built in commands and zsh which resembles the Korn shell (ksh) and is well known for its command line completion.

The original UNIX shell was called sh, but these days is likely to be a symbolic link to another shell like bash.

BOXOUT 2
Reusing Commands with the History List

The bash shell keeps a history list of commands that have been typed and run on the command line.

Instead of retyping a previously used command, the list can be scrolled with the up and down arrow keys. Commands can also be accessed by list number or by a few of the initial letters of the last run matching command. The command line history is accessed by preceding the number or pattern with an exclamation mark (!). The history is listed with the command “history” which prints each command preceded by its number.

If the list contained just these three commands

1 ls
2 ls /bin
3 echo “Hello”

!e would run the third command, !1 would run the first command and so forth.

BOXOUT 3
History Operator Short Cuts

The command line history expansion operator !! can be used with a word designator to perform shortcuts in command line typing.

If you typed in the command

ls /usr/local/src/myprogram/docs/installation.txt

and then wanted to edit it with vi, you can use the history operator and the $ symbol like this:

vi !$

which replaces !$ with the last argument of the immediately preceding command, saving a lot of typing.

!$ is a short form of the real history expansion command !!:$ where !! means the preceding command, : separates the command from the word designator, and $ is a word meaning last argument.

So to use vi to edit the first argument of a previous two argument command like

ls readme.txt installation.txt

you would type

vi !!:1

BOXOUT 4
Tab key Short Cuts

The Tab key is very useful on the command line for finding out the names of programs of which you remember the first few letters, and for completing paths.

If you type “firTab” you may get “fire” at the prompt which tells you there are some commands starting with “fire”. If you press Tab again a list like this will appear

firefox fireglcontrol fireload_cpu fireload_file

with “fire” still at the prompt waiting for you to type more letters. Since there is only only command shown with the next letter being a “g”, typing a further “gTab” will complete the “fireglcontrol” command which will execute when you press the enter key.

To complete paths with the Tab key the operation is similar. If you don't give enough starting letters for a unique name it will print out all possible names in the folder in the path. Thus to use the Tab key to complete the path /usr/local/src/myprogram/docs/installation.txt

you could type /usr/loTab/src/mypTab/doTab/insTab.

by Simon Bridge on Sat, 2006-04-01 23:05
Infomercial time?

Quote:
Back in the last century many women end users found that using the UNIX tools was really as easy as writing out event orders for a parties, and managing a household, so I hope many of you read and enjoy this series.
Cringe!
Sure - and we all enjoyed our hot date: Dinner At Home.

Mind you - the strategy of describing the lin/unix cli commands as "power tools" is kinda neat and one I am bound to steal later, however, this seems to be aimed at a specific product.

The product in question adds a gui interface to the traditional shell. The effect seems to be to make shell scripting more complex than just typing. So I guess you've lost me on this one.


  



All times are GMT -5. The time now is 02:44 PM.

Main Menu
Advertisement
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration