Now, explaining command line variables. They are numbered from left to right as you type them. If you have three arguments, then you have variables $1 $2 $3

$@ means all command line arguments
$# means the number of arguments

In this example we use the case statement to determine which commands to run. And this is your first viewing of case in this study

The information we give case is $# which is the total count of our arguments. Valid matches, (true conditions), are 1 to 3. If we don't give case a number between 1 to 3 arguments, then * is true and it echos an error and does nothing.

To install these scripts, download the package, use Midnight Commander to open the zip package in a virtual filesystem and copy the three scripts to /root/bin

findf is for finding files
findd is for finding directories
updatedb is for building the databases

findf means find files
findd means find directories
First run updatedb to build your database, then run findd and see if you can locate the directories containing pixmaps and icons.

Remembering, we don't want to type too much, if you want the output of a line, just double-click it to select it and shift+insert or push mouse button to paste the text on your command line or into an editor. Useful when writing scripts to make sure you don't make a typo.

Suppose you want to change to a directory in your output, type cd (space) in the command line, then paste the directory to the command line and hit enter.

There are many ways to keep from typing too much when using the command line, in time we will learn more and more

This chapter is short, sweet and important. I'll tell you why it's important. In the thousands of posts I've read on the forum, I seen many, many posts were it's obvious to me the problem is somewhere in the directory /etc

But I can't tell remotely exactly what the problem is.

/etc is not a static directory like /bin. /etc changes some every boot. Usually what brings on the users problem is a bad shutdown. Then, they can't recover.

I'll talk a little about tar. We only run one utility here, tar, but tar works in conjunction with gzip (or bzip2). So we are running two utilities, although it doesn't look like it.

A .tar.gz file is very, very common in Linux. You will also find you can make and extract tar.gz archives very easily with Midnight Commander, simply hit the F2 (the menu) key to intuit how.

Tar makes the archive, but it's uncompressed, gzip is the utility that compresses the tar archive. This is why the two extensions, tar says a tar archive and gz says compressed by gzip. But sometimes it's displayed as .tgz. When you encounter a .tgz or tar.gz file, just know it is the same thing, described differently.

Not so hard. You already have the tools and know how to easily make the script - bkup-etc, so do it.
/root contains your user settings and maybe important files. If you have the space to backup /root - I recommend doing it - use bkup-etc as your template for making the script.

The etc.tar.gz will be about 1/2 megabyte

If /root is too big for pup_save, you could do something like this:
tar cvzf /mnt/home/root.tar.gz /root

I'll leave it to you as an extra-curricular kind of thing to figure out the logistics.

After you've used ad a bit, I'll explain it. Part of what I'm doing in these earlier chapters is helping make your TUI environment as user friendly as possible. Soon, quite soon, changing directories on the TUI will be easier and faster than with the GUI, but it doesn't start off that way.

In our last chapter, we made aliases, a function and installed a shell script. In this chapter I'll present theory for the whys of our whats.

Changing directories in a shell script

Remembering that our shell script is a child process, if we change directories in a script, we will change directories in the script. When the script is finished we are in the same directory we were in when when ran the script.

This script called usrbin;

#/bin/bash
cd /usr/bin

will actually do what it says, but when it finishes we are left in the same directory we ran it from.

Changing directories with an alias

This alias of the same name: usrbin
alias usrbin='cd /usr/bin'

Actually changes our current directory to /usr/bin, just as if we typed the commands. This alias doesn't launch a child process, thus giving the desired results.

For our purposes; whitespace could be defined as characters which don't display.

Our most common text editor whitespace characters would be line endings, space and tab characters.

In bash we have the backslash \ character, an instructoion for the bash interpreter.

For this post I'll define \ as the 'do something different for the next character character'

In bash, the end of line (eol) character is the signal for end of command.

Sometimes I post code and have you insert the code, other times I don't post the code and have you download it.

Here is an excerpt from the file 'ad' in chapter 17

Code:

find -maxdepth 1 -type d | cut -b 3-80 \
| sort -g | mkfiles

Note the use of \, it says do something different about the next character, which is the eol character, (0x09). What it does different is; bash doesn't treat the whitespace, the eol, as a signal that the command is complete.

It continues the command execution to the line below. Without the \ character the command would need to look like this:

Code:

find -maxdepth 1 -type d | cut -b 3-80 | sort -g | mkfiles

Sometimes we make very long commands, longer than our text editor can display and longer than a forum post will safely display.

The forum will use the space character as a delimiter for line wrapping. We don't know our reader's font size or screen resolution. Because of this, we can get unwanted line wrapping with long code excerpts.

The long code might wrap at the wrong place. If the user copies and pastes code which the forum has wrapped (at the wrong place for code), the code will likely be very defective.

With the code block below, it is imperative that no white space follow the \ except for the end of line character. By using the \ we have to be sure the character we want to treat differently is actually - the eol character - and not a space character.

I didn't post the code, because I don't want it copied from the forum and have someone inadvertently insert a space character. To be safe, download it, because if I'm doing my part right, there are no boo-boos in the in the code and it will run as expected.

Many people associate learning with pain. I expect if you are even reading Chapter 21, you aren't one of these types of people. Or if you are, you have enough determinism and desire to learn not to let the pain association be a deterrent.

At this point of your learning experience, I'd like to state or restate, some of what I'm doing.

1) I'm trying to gradually help you set up a more friendly and powerful TUI environment than the one you started with. In doing this I might find myself a bit a cross-purposes with another objective, which is;

2) teaching bash scripting on an easy to learn gradient.

Obviously, I want you working in as friendly and powerful environment as possible. We build this environment gradually.

If you find some file unexplained and over your head, it is very possible, I'm trying to help with number (1). Explaining every aspect of a file may be on too steep a gradient for number (2), it might remain unexplained for this reason.

If you run into a situation like this, I advise; do not try and understand the file or procedure, if it is too hard, especially if stands to reason its purpose is in category number (1).

Two requisites defined for the bash programmer

1) Understanding the directory tree and files

2) File management skills

Two requisites explained

If you don't have a solid grasp of the directory tree and files, your file management skills will be lacking. Your programs will not be as expansive as they otherwise could be. Lots of what we might want to do in scripting pertains to file management.

Optional self-learning assignment

( Midnight Commander is a powerful file manager and just by using it, you will become gradually more familiar with Linux' directories and files. ) ( have you noticed with mc, you don't need to extract the .zip package and many other packages to copy files out of them? )

1) download the package tree.zip, its contents are one binary named tree and one text file called tree.txt which is the --help for tree.

At this point, no instructions should be needed. Simply put the binary file tree it it's appropriate directory and the documentation tree.txt in its appropriate directory.

2) using the Internet search, find a page which helps you to learn Linux default or basic directory tree. Read it and learn the basics, ( if you need the instructions at all ).

The echo command is internal to our command processor, bash. How to know?

Type help and see if echo is in the list

In Puppy, the echo command may also be an external command. How to know?

which echo
and/or
ls -l /bin/echo

The rule is: an internal command will have precedence to an external one. However, if for some reason we wanted to use the external one we could, if it exists, by specifying the full path;

/bin/echo

Using echo

We typically use echo for displaying something to standard output (or in redirection). I want to emphasize echo's abilities go beyond what it is typically used for:

How about math? Try this command:

echo $[5+23]

Displaying files, try this:

echo *

Using quotes as a safety net

Until we learn the ins and outs and the peculiarities of echo, I recommend quoting what you wish to display. By quoting your intended output in your script, you are more likely to have the results you intended.

echo "My last directory was: $OLDPWD"

echo's default is to give a line feed at the end of the line. Remember from earlier the 'eol' is a non visible character, but it affects the formatting of our output.

echo -n says don't use a line feed. Let's try the above command with echo -n as follows;

Good, this is an available command name. We will call the our new command: cecho
It means; color echo

cecho usage:

cecho color "text for screen display"

for no new line;

cecho color "text for screen display" n

The cecho function, displayed in its present form, but I want to refine some things before you install it. The refinements and install instructions, will have to wait until next chapter. (or the next, next) Sorry. I'm starting to learn what they mean when saying, "Rome wasn't built in a day."

In this chapter we will work together and build a function based program. Programming begins with an idea. I have an idea that I would like you to be able to easily, very easily, as easy as possible make practice scripts.

I will title the program 'fun' and if that name doesn't suit you we will write it so you can change its title.

Scripts run commands. Scripts read from top to bottom. When I build a completely function based script, the first command is at the bottom. Putting it on the bottom means bash has read the entire script, (its functions) before any program execution begins.

The 'explanation formatting' in this chapter will be first the script, followed by explanation.

Code:

#!/bin/bash

main() {

echo

}

main

We now have a complete script that only echoes a linefeed. The reason for the echo command is bash doesn't want us to leave our functions empty. Echo doesn't fill our need, rather a bash demand.

begin the execution of the while loop. while loops as long as our condition is true, which we've define is the variable quit=1, if something happens where the variable quit equals anything else, the loop stops running

cnt : note we increment it by a numerical value of 1 each time the while statement loops

if [ condition check ] : we are looking for a file that doesn't exist. the filename is fun# , which is the variable cmd plus the variable cnt

echo -e \\n\\n >> $file : adds two linefeeds

when we find a fun# file that doesn't exist, we make the new file, give it executable attributes, and open it in our 'guieditor'

For the purpose of this chapter, and not being an astronomer, I'll define a black hole as something that tends to absorb light. The light being your consciousness and the black hole being what tends to leave you in the dark.

In computing, I'd call the command line itself, a black hole for many. The Windows registry for others. Also the MBR.

I hope to shed some light on the MBR (Master Boot Record) in this chapter.

I've read forum topics where the OP had a bad MBR, or thought he had a bad MBR. Then from 10 to 30 or more follow up posts trying to help the OP.

On your partitioned hard disk your MBR will be the first physical sector of the hard disk.

Introducing dd - a copy / convert command.

Save a copy of the MBR:

dd if=/dev/hda of=hda.mbr bs=512 count=1

Restore the MBR from the copy:

boot to the command line
cd to the location of hda.mbr
the commands listed below are a bit more than necessary, but we really want to do this right or not at all.

sync
dd if=/dev/hda.mbr of=hda.mbr bs=512 count=1
sync
reboot

(sync flushes pending buffered writes held in memory)

Tips:

I can't tell you if it is /dev/hda, /dev/sda or something else, not with Puppy. Puppy changes. I can (later) tell you how to tell the Linux designation for your hard drive.

It is good to have a copy of your MBR. If the copy is of /dev/hda, it is best to save a copy on another device. The reason why is; if your hda MBR really goes bad, you may not even be able to access the drive to get to your backup MBR.

So, save it on a floppy disk, USB stick or some place other than hda. But also save it on /dev/hda because in most cases hda will be accessible and you can use the backup MBR from it.
Why the MBR goes bad

Usually, it never changes. It shouldn't ever change. But when we install various operating systems, we run the risk of it changing the MBR in a way we don't want to, or a dumb install routine changing it in way we really don't want. ( discounting the very unlikely event that our own stupidity isn't the cause )

When to save a copy of the MBR

Immediately after every time we modify our partitions. Especially primary partitions.

If you end up not deleting an earlier MBR, need to restore and become confused which backup to use, use the ls command like this:

ls -l <filename>

View the date and this will help determine the date of your backup, by reading the date in ls output - it should correspond with the date you partitioned.

We could also make dated backups. But we've not been introduced to the Linux date command yet.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum