With this utility you can type in doks and easily read the files in this directory with your new pager. (if they are the right kind of files)

What I'd like for an assignment is to have you modify this file some, give it colors, change the color of PS3. Change and color the title, so on and so forth.

You can setup these simple little menu systems throughout your system as needs be. For example, I have scripts to run wine supported files. I type in 'winem', short for 'wine menu' and then select the number of the application I want to run.

The wine scripts have their own place in the PATH so I can run them directly also with command line arguments. And while on the subject, you can add lots of paths to grow your system and keep it organized.

A little change of subject, but while I'm thinking about it, when we installed mrxvt it didn't come with a complete rc file. I made a complete file, not all the values are entered, nor should they be, but the options are. With the rc file, it's easy to change the way mrxvt looks and behaves. And of course see the options available which the other file didn't show.

I'll attach it as mrxvtrc and you can download it to /root and use

swapf mrxvtrc .mrxvtrc

Would you like a utility for swapping directories? If so, you can use swapf as the template. Copy it to the name swapd and change it internally, accordingly.

The hex editor is the right tool for the job, unless you insert or delete bytes the byte size of the file doesn't change. The hex editor displays all content.

I compiled gqview and found out it wanted its help file from a subdirectory of my temporary build directory.

I edited the directory string in the file to point to the right place. It only took a minute and beat debugging the source code.

------------

More recently, as in today, I was using a really neat PIM (Personal Information Manager)

It has (had) 1 pane for a todo list, 1 pane for the calendar and one pane for the appointment list.

Problem is I don't have many appointments. But I do have goals and the way the PIM is organized goals work perfectly in place of appointments. So I hacked it replacing this string
Appointments
with this
Goal Planner

These characters are only for display purposes and the number of characters I replaced was identical, so the file size didn't change, which you really likely don't want to do.

I've attached a little picture of the changes.

The idea I wish to convey in this chapter is don't be afraid to change some human readable text. ( you followed rule number #1 and #2 )

Generally, when you are inside the file, you can intuit if the text you plan to change is okay to change.

Sometimes we need to add and remove file name information. I'll show an example. Suppose we wanted to decode .mp3 to .wav files with lame.

Lame's syntax is like this lame -decode <infile> <outfile>

For 16 songs that would be a lot of typing. If we want to do a good job we want the outfile with a .wav extension and not a .mp3.wav extension.

Suppose our files are named like this Track_01.mp3, Track_02.mp3, . . .

We have an advantage from the start because we know the infile extension.

Puppy comes with an external utility called basename. Basename will strip the directory name from our file, if the directory name exists, but it won't strip the extension unless we tell it what it is.

Back to the old for loop.

Code:

for i in *mp3 ; do
fn=`basename .mp3`
lame -decode ${fn}.mp3 ${fn}.wav
done

When the loop is done, we have 16 .mp3 and 16 .wav files and it didn't take typing. Note this would be a reusable script.

It wouldn't handle song names with spaces, but as the administrator of your Linux system, I think you are better off not introducing file or directory names with spaces.

The idea in this chapter is showing the utility basename and how to remove and change extensions. If you 'got' that much you got it. There are other ways to capture extensions and remove them. I'll save that for later.

It is very common convention in Unix that our binary files and our shell scripts are put together in the /bin and /sbin directories.

Suppose we want to have a directory with just scripts, maybe for the purpose of studying the scripts on the system. To manually go through the directories, prune the scripts from binaries, and copy out the scripts would be a lot of work.

The quotes or the x don't actually exist in either string. We use them as place holders, to make sure there is something to compare with. We can't compare something to nothing and bash will give us an error.

If FILE is specified, read it to determine which colors to use for which
file types and extensions. Otherwise, a precompiled database is used.
For details on the format of these files, run `dircolors --print-database'.

I had about 95 MB free and then it was 0 MB free. Thinking back, I couldn't remember when I downloaded something that big. So, it was time to troubleshoot and locate where the free space went. After discovering where the lost space was, I can back track and explain.

The behavior of mount points

In Linux we can mount filesystems on just about any mount point, (directory). The mount point does not need to be empty to use it as a mount point for another filesystem.

/mnt/hda1 is merely a directory inside my pup_save file. That's all it is - a directory. But I use it as a mount point for /dev/hda1.

If /mnt/hda1 is not mounted, I could view any files inside it. But if I mount it, the files would no longer be shown. The viewable files would be the files in the partition /dev/hda1

What would happen if I copied, moved or downloaded files to /mnt/hda1 ?

If it is not mounted they would be placed inside /mnt/hda1, which is inside the pup_save file, thus increasing the used space in the pup_save file.

But if /mnt/hda1 were mounted, the files would be placed inside /dev/hda1 and would not increase the pup_save used space.

I guess you can figure out what I did to fill up pup_save.

Introducing the utility du

du has many switches, modes of behavior. I made this script called disku (the u meaning usage)

Code:

#!/bin/bash
du --max-depth=1 --one-file-system | sort -n

The --one-file-system says don't operate on other file systems. --max-depth=1 means just show me the first level directories.

After running the script I noted /mnt was bigger than it should be.

The file sort also has many options, the -n switch arranges du output sizes in ascending order.

-----------

Summary: In this troubleshooting scenerio, I didn't even have a script to do the job. However, I knew the external tools existed and what they did.

How could I have made this simple script without knowing about the tools available? Not very easily. The 'secret to success' in this case is in knowing the utilities available to us.

In the course of these chapters, I'll try and make sure you've been introduced to virtually all the common utilities.

First, I'd like to discuss reasons why you might want a RAM drive based mainly I suppose on reasons I've wanted RAM drives.

1) With MS-DOS, I used RAM drives for speeding up execution of batch files, holding some commonly used utilities and as a temp directory.

2) Later as RAM became cheaper, I learned how to load the entirety of Windows in RAM. This made Windows fairly invincible, because even if some kind of corruption happened, it would disappear after reboot.

3) With Linux, I like RAM drives as temporary work places for files which have no life expectancy, such as the files used in scripting or things like ripping a music disc and converting the wav files to mp3s. The RAM drive is fast and it's no wear and tear on the hard disk.

4) (Many of my scripts manipulate files and I have a wrkdir variable pointing to a RAM disk.)

----------------------------

I don't know that you need or want a RAM Drive, or this kind of RAM Drive. Or if you already have one. Nevertheless, I'll show how.

Pick a ram device and a mount point

In /etc/rc.d/rc.local

mke2fs -m0 /dev/ram3
mount -t ext2 /dev/ram3 /mnt/ramd

Puppy's default will usually give about a 14MB drive, this size can be increased on the kernel line, like this;

This type of RAM filesystem is very common. I've seen it called an shmfs (in older days) and more currently, tmpfs. The mount point has always been /dev/shm. But should be able to use other mount points.

Some Puppys have this filesystem and some don't. I think I even saw one version were /tmp was a symlink to /dev/shm.

My Puppy didn't have the tmpfs, so I made one. First step is adding this line to /etc/fstab;

Code:

tmpfs /dev/shm tmpfs noauto,rw,noatime,nodiratime 0 0

then in /etc/rc.d/rc.local run this command;

mount /dev/shm

You can also mount a tmpfs /dev/shm with a full set of mount instructions, but why bother? One fstab entry makes it much easier.

The default tmpfs size is 50% of RAM

You can change the size with this parameter, in fstab;
size=800M (if you wanted an 800MB tmpfs, I use 800 MB for CD copy)

Code:

tmpfs /dev/shm tmpfs noauto,size=800M,rw,noatime,nodiratime 0 0

This type of filesystem doesn't actually deplete your RAM.

I conceptualize it this way. The first type of RAM disk I showed is static in size on not accessible for paging. Tmpfs is dynamic, and used as a part of available memory, sort of like a swap file in RAM. (A RAM disk that doesn't really use RAM?)

I don't want to say which is better, because the answer is likely dependent on what it's used for.

I use the /dev/shm for SeaMonkey's disk cache set at 100MB. Also as my $wrkdir. And for major work like copying a cd disc.

Sorry for few weeks lost making new chapters. This is not a work completed. There is a story about the lost time. One I hope you find of some interest.

I've been doing this project on a highly modified Puppy version 4.00. I wanted for us to be able to convert man pages to HTML or text format. I thought Puppy had a file called man2html, but wanted to be sure. It appears it didn't.

I decided to build a new Puppy, one which would lend itself better to this project. With me doing things different, like keeping a log of changes, having fresh pup_saves for testing, keeping addon files in separate directories and etc.

So, I setup a new Puppy and added many applications, even put together a new Midnight Commander. Then, the fateful day. I ran a filesystem check and found it was full of errors.

I decided, no way. I'm starting over with a pup_save with a ext3 filesystem, not the default ext2. For about a year and a half now, I've been using ext3 with virtually no file system errors, and I might add, under very heavy usage.

Then my cable modem went bad. Then I decided to upgrade the firmware for my old Linksys router and the upgrade went bad. So buy a new router. While I'm at it how about a controller card for another drive? Why not extra DVD discs and, what would be wrong with a new Plextor burner?

Well you get the picture.

--------------

The part that bothers me from an 'us' perspective is the excessive ext2 file system errors.

What you can do is something along these lines, if you are using Frugal on an HD (probably a RAM stick also), for the purpose of checking.

1) boot using the puppy pfix=ram option
or
2) add a extra small pup_save file about 32 MB

Find your pup_save file, run e2fsck -f on your pup_save file and see if you are getting too many errors.

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