Chapter 3

The Linux commandline

You've got Linux installed, and you want to learn how to use it!

I suggest that you read through this chapter now, with the PC running. Try things for yourself as you go. The concepts presented in this fairly small chapter are introductory and simple, and will give you a basic understanding of the Linux commandline and some underlying operating system principles. Do not leapfrog this chapter and start learning about KDE and KOffice -- well, if you just can't wait, be sure to come back here sometime soon and work through every section.

Note that many of the topics of this chapter overlap with or fall into the scope of Chapter xxx, Configuration and maintenance. I have placed information in this chapter that I think is most useful to know up-front, when you are first learning about Linux. Other stuff, still important, but information that you are likely to need later, and also maybe more complex, has gone into the latter chapter.

The Linux/MSWindows saga

The concept of the commandline

All users of MSWindows know about MSDOS. For some of us, MSDOS is an old friend. The very first IBM PC, back in ... when was it now? ... 1981, had MSDOS version 1.0, and this was quickly followed by upgrades, until version 6.2. The situation always was that you needed to have MSDOS installed on your PC, and MSWindows was an application that ran on top. At least this was the situation until MSWindows 95, when Microsoft no longer sold MSDOS as a separate product. It was still there however, and on power-up the PC would first load MSDOS then MSWindows. The difference was that Microsoft tried to hide the fact.

In the MSWindows 3.x days, first MSDOS would load, and your PC would display the MSDOS prompt, awaiting a command. By typing "win" you would launch MSWindows, and up would come the graphical user interface, which was the famous desktop metaphor, stolen from Apple Inc. (says Apple), which was in turn stolen from Xerox.

I mention this MSDOS/MSWindows history, as Linux has some similar parallels. Traditionally, Linux was a text-mode terminal based system, displaying a prompt and awaiting a command, just like MSDOS. Again, graphical user interfaces and desktop metaphors were add-ons, just like MSWindows. Linux is only now getting to the "MSWindows 95" phase, in that power-up will go straight into the graphical environment, bypassing the text-mode commandline. If you go out and purchase a Linux distribution, it may fall into the "MSWindows 3.x" category or the "MSWindows 95" category. In other words, the default behaviour may be that when you first boot into Linux, you will be at the text-mode prompt, or you will go straight into a desktop environment.

What is the difference? None really. It is a matter of preference -- some people, especially seasoned Linux users, prefer to bring up the prompt first. Some die-hards don't like the graphical environments at all, and prefer to stay with text-mode applications. Please be very clear that there is a world of difference between the Linux commandline and MSDOS. For Microsoft, MSDOS had become an embarassment. It is a 16-bit Real-mode single-tasking operating system, full of inconsistencies. Maintaining backwards compatibility, that is, being able to run all the old MSDOS applications, was a millstone around Microsoft's neck. They tried to hide it with the release of MSWindows 95, and have progressively de-emphasised its use.

The basic Linux operating system on the other hand has none of the limitations of MSDOS. Right from the start it allowed long filenames (now up to 256 characters). It is multitasking, multiuser (which even MSWindows NT isn't, not really), and makes full use of the underlying processor's Protected-mode. You could say that it is a 32-bit operating system, which is the case for the 386-Pentium family, but Linux is written almost totally in C and has been compiled for 64-bit processors also. In fact, Linux has been compiled for just about every type of computer, even for that old Amiga you have in the garage.

So, the Linux text-mode commandline is not something to be hidden away and forgotten. Most new users are however tending to access it from a console or terminal box launched from inside a graphical desktop. You can of course do the same thing from inside MSWindows 9x, by double-clicking on the MSDOS icon, however the same old embarassing MSDOS is then launched. The Linux commandline is totally equal and as capable as the graphical environment, and will always remain as a useful tool.

Linux differences from MSDOS/Windows

When you first have the Linux commandline prompt appearing on the screen, you will find some reassurance in that it works somewhat like MSDOS. Yes, there are directories, and yes, good old cd (change directory) works also. However, there are disconcerting differences. For example, dir (directory) is replaced by ls (list), and the \ (back-slash) is now / (forward-slash). Even more disconcerting is that the directory stucture seems odd -- where are the A:, B:, C:, D:, etc., drives? Oh dear.

What you will find is that the differences are not too many, and you will soon feel at home. You will also discover that some differences are there for very logical reasons. For example, the forward slash to specify a path, for example /home/bkauler/afile.txt, is consistent with the forward-slashes as used worldwide over the Internet. ftp://ftp.cowan.edu.au/home/bkauler/afile.txt is a possible Internet address, which is obviously better than ftp://ftp.cowan.edu.au\home\bkauler\afile.txt!

Unfortunately for Microsoft, having peddled the back-slash for so long, when a MSWindows NT system is setup as an Internet server, it has to recognise the forward slash. Though, I have encountered those that don't (which may be MSWindows 9x servers, perhaps).

Another thing that you will never see on the Internet is an address like ftp://ftp.cowan.edu.au/C:\home\bkauler\afile.txt. That is, a physical or logical drive letter, such as C:, is never specified. However, the entire edifice of MSDOS and MSWindows is built around a file system hanging off drive letters A:, B:, C:, D:, etc. Obviously an Internet server PC can have any number of physical and logical drives, yet the files on these drives are accessed by pathnames that don't have drive letters.

Once again Microsoft has had to swallow it's pride, and dump the drive letters. In fact, the file structure that Linux has had all along is basically what is now used by Microsoft also.

Obviously there are a lot more differences between Linux and MSDOS/Windows, but what I have touched on in this and the previous section is that Linux is extremely well designed, being essentially Unix, which in turn is an operating system designed for minicomputers and mainframes. Other differences will emerge as you study the rest of this chapter. MSDOS has gradually stolen ideas from Unix, and MSWindows has continued this. So, it is not a question of "is Linux as good as MSWindows?"; it is more appropriate to ask "when will MSWindows be as good as Linux?"

Let's get some hands-on. The first thing to understand is the file structure, which is covered in the next section. Subsequent sections cover various commands and aspects of using Linux at the text-mode commandline level, and you will need to refer to them as the need arises. When you feel that you can navigate around and perform basic file management functions, proceed to the next chapter.

File system structure

There is a very important reason for not having drive letters; they are incredibly restrictive. Many people will have had the experience of a C: drive that is full, and although they may install a D: drive, still, software insists on being installed on the C: drive and won't work on the D: drive. Well, I've had that experience anyway.

But this idea of "restrictive" can be better explained. Say that you have a directory C:\customers\, into which you put all sorts of stuff, maybe heaps of subdirectories for your various customers. Until one day the drive is full. With MSDOS/Windows, you can't put anything more into that directory. If you purchase another drive, you will have to create a new directory structure for it.

Now this is where Unix/Linux is beautiful. Read this carefully:

In Chapter 1 I explained how to install Linux, and a drive partition, say hda6, will have been assigned as the root of the file structure. That is, it will be mounted at boot-up time as the "/" of the file structure, with the hierarchy of directories expanding below it.

Just recapitulating from Chapter 1, it may be that your hard drive is named as hda and CDROM drive as hdb, and you may have partitioned hda with hda5, hda6, and hda7 -- this is an example only, as illustrated in Figure 1.7 (page xxx).

The essential point here is that a drive partition has been assigned as the root, and the directories and sub-directories expand below it. So, what about other drives, such as the floppy, the CDROM, another hard drive? Very simply, these can be mounted into the same file structure. That is, hda6 (for example) will always remain as "/", but any directory or subdirectory below it can be another drive or drive partition.

Normally, the directory /customers/ will be on hda6, but if hda6 becomes full, you can install another hard drive and mount it as /customers/. In other words, when you are looking at the files in "/", you will be accessing drive hda6, but if you look at the files in /customers/, you will be accessing drive hdc (say). But, as the user you are unaware of this. Absolutely any directory, although it may appear to hang off the root path, can be in fact physically on another drive or drive partition. This means that the file structure is indefinitely expandable.

With Linux, there is a directory called /mnt/, and it has subdirectories /mnt/cdrom/ and /mnt/floppy/. These are where you can mount the floppy drive and CDROM drive, and you would simply do this:

$ cd /mnt/floppy/
$ ls

to see the contents of the floppy drive.

However, this raises another issue, that newcomers find rather annoying. With most Linux distributions, the floppy and CDROM drives are not (by default) automatically mounted at boot-time. Rather, it must be done manually.

This topic is worthy of its own little section, which is in Mounting a drive (page xxx). For now, continuing with an introduction to the file system.

When Linux is installed, a number of directories are automatically created. Most importantly, you should have an idea what the various directories in the root directory are for:

Some of these require further explanation.

/bin/, /sbin/

This is where you'll find the really basic Linux binary (executable) files. For example, ls* (list), mkdir* (make directory), and vi* (a text editor). /sbin/ has somewhat more sophisticated executables, such as lilo* and fdisk*.

/dev/

You may need time to get familiar with this concept. All hardware devices, physical or logical, are treated as files in Linux. So, the first serial port is /dev/ttyS0 (/dev/cua0 in older systems) and the CDROM drive is /dev/cdrom or /dev/hdb (for example). The usefulness of this can only become clear as you perform actual configuration operations involving these devices.

/etc/, /var/

Mostly you will find text files in here, that are configuration files used by Linux and by applications. There are also subdirectories, installed by applications, to group each application's configuration files.

/mnt/

As already explained above, a drive partition can be mounted anywhere in the file hierarchy, but it is traditional to mount the temporary file devices into a subdirectory in /mnt/. Debian Linux is one exception to this, as two directories /floppy/ and /cdrom/ are created at install-time, hanging off the root directory, not inside /mnt/.

/opt/

An application that is not part of the Linux distribution may install here. I found that KDE as obtained by download from http://www.kde.org/ by default installs into /opt/kde/, but KDE as supplied by some other Linux distributors installs into /usr/. It seems that /opt/ is not much utilised.

/home/

Linux is a multiuser operating system, right from the start. As such, each user has to login and has a username and password. A normal user has restricted access to the system. When a user logs in, he/she will initially be in their home directory. For example, if my username is bkauler, I will have a home directory /home/bkauler/. This is where I keep all my personal stuff, and most importantly it is also where applications keep my personal configuration files. With regard to the last point, any change I make to the KDE desktop will be stored in my own personal KDE configuration files, so anything I do to KDE won't affect other users. Great stuff.

/root/

It is extremely important to note that a directory called root is not the same as the root directory, which is "/". The directory /root/ is the home directory for the root user, also known as the superuser. This person has unrestricted access to the system, and power over all the normal users. When you login as superuser, you will initially be in the /root/ directory.

An ideological point here. If you are the only one who uses your PC, why bother with user accounts? Why not always login as root? Certainly, if you are fiddling around with the system a lot, installing and uninstalling programs, and forever reconfiguring things, there is a convenience to always being the superuser. I confess that with the system that I'm using at the moment I always login as root, and I know other people who do the same thing. However, it is not considered desirable, especially if you are a newbie who doesn't quite know what they're doing, and especially if you let the kids use the PC.

Commandline operations

Linux is supplied with what is called the Bash shell. Those of you familiar with MSDOS will know that when the PC is powering-up, a file called COMMAND.COM loads from the boot disk. This file is then executed, and you have the MSDOS prompt. It is COMMAND.COM that is running when you are "in DOS", and it reads the keyboard and interprets whatever you type. Some commands that you type are interpreted and executed within COMMAND.COM (such as dir), while others are separate programs (such as format.exe). This commandline interpreter is called a shell in Linux, of which there are several. The capabilities of the various shells differ, but as Bash is what you get by default with Linux, Bash is all I have covered in this chapter -- mostly though, I've been general enough to cover all shells, except for a few points, such as description of a file called bashrc.

This section is written with theory interspersed with hands-on examples, so please have your PC running as you read.

Mounting a drive

Commands described in this section:

Note that cd*, mkdir* and ls* commands and the vi* text editor are also referred to in this section, but are described in following sections.

I have established in section File system structure (page xxx) that a drive or drive partition can be mounted anywhere in the file hierarchy.

For example, the CDROM drive can be mounted to /mnt/cdrom/. What also should be appreciated, and this is something very great, is that Linux supports a range of filesystem types. The standard Linux filesystem is called ext2, but Linux also understands the old MSDOS filesystem (msdos) and the MSWindows filesystems (vfat and win32). Then there's hpfs, xiafs, ext, iso9660, and minix.

KDE has a very easy way of mounting a drive, but the old-fashioned way is to execute the mount command at the commandline. For example, to mount the floppy drive:

# mount -t vfat /dev/fd0 /mnt/floppy

Or, to mount the CDROM:

# mount -t iso9660 /dev/cdrom /mnt/cdrom

The -t option enables you to specify the filesystem type to be mounted. vfat is better than msdos, as it recognises long filenames. win32 is MSWindows latest filesystem type, that allows very large hard drives. However, the -t option is optional, as there is a default filesystem type specified for each drive or drive partition. This information is contained in a text file called /etc/fstab. Here is a typical fstab file:

/dev/hda6       /            ext2    defaults        1 1
/dev/hda5       /boot        ext2    defaults        1 2
/dev/hda7       swap         swap    defaults        0 0
/dev/fd0        /mnt/floppy  vfat    noauto,user     0 0
/dev/cdrom      /mnt/cdrom   iso9660 noauto,ro,user  0 0
none            /proc        proc    defaults        0 0

As you can see, this is a very useful file. By the way, you've got to be logged in as superuser to edit it!

The second column shows where in the file hierarchy a drive or drive partition mount to. The third column shows the default filesystem type. The fourth column specifies some options. noauto means that the drive has to be mounted manually. user means that any user can do it -- if you didn't have this option then only the superuser could mount the drive.

Or rather it would depend on the permissions of the device -- see Hardware permissions (page xxx).

ro means read-only, which is appropriate for the CDROM (mostly, anyway!). This means that instead of typing all the stuff as I did above, to mount the floppy I could type just this:

$ mount /dev/fd0

And the defaults would be used. Notice also the $ prompt, meaning that an ordinary user can do this.

want to know more about mount and fstab? Linux uses the Unix system of manpages. This is a help system, and you activate it like this:

$ man mount
$ man fstab

The man* program will bring up a help document on the specified topic, a windowful at a time, and you hit the <space> key to bring up the next window, and the <q> key to quit. In fact, you can get information on man* itself:

$ man man

Now for something exciting -- you can even mount the MSWindows hard drive partition. Let's say its hda1:

# mount -t vfat /dev/hda1 /mnt/cdrive

Note that the directory /mnt/cdrive/ must have been created beforehand.

There are a couple of things that I haven't explained so far; how to edit a file, and how to create a directory. Obviously, if you want to view and edit fstab, you need an editor, and if you want to mount the MSWindows C: drive, you need to create /mnt/cdrive/ to mount it to.

One of the old standard text editors is vi, nothing brilliant I warn you -- look in vi text editor (page xxx).

To do simple file and directory manipulations, such as create a directory, look in Manipulating files and directories (page xxx).

Would you like to try it? Presuming that you know the Linux name for the C: drive, in this example hda1, login as root, create /mnt/cdrive/, and try the mount command:

# cd /mnt
# mkdir cdrive
# mount -t vfat /dev/hda1 /mnt/cdrive

Then, go in and poke around:

# cd /mnt/cdrive
# ls -Fa --color

Note of course that if /mnt/ is already the current directory, then it is only necessary to type "cd cdrive", just like you would in MSDOS. ls is the list command, similar to MSDOS's dir.

ls is described in Listing directory contents with ls (page xxx).

When you have finished, you should unmount it;

# umount /mnt/cdrive

or

# umount /dev/hda1

Either of these will do the job.

xxx - put in something about /etc/mtab !!!!!

Listing directory contents with ls*

Commands described in this section:

Note that the cd* (change directory) command is also mentioned in this section, but is introduced in the next section. Note also that the Bash shell accepts the dir* command as equivalent to ls* -- for those people who can't give up old habits! I do suggest though that you get into the spirit of things, and migrate to ls*.

By the way, you can do yourself a favour by configuring the list command ls* to permanently show which files are text, executable, link, or directory. ls* is the same as dir in MSDOS. One of the problems with Linux is that executable files do not have to have an extension .exe or .com as required in MSDOS -- they can have any name. So, if you get a listing of what's in a directory, how do you know what is a text file, what is an executable, what is a link, and what is a subdirectory?

The answer to this problem is that you can tell Linux to append "*", "@", or "/" to the end of the filename, and by colour coding. In your home directory you have a file called .bashrc which is like AUTOEXEC.BAT, except this one is just for you, and anyone else who logs in will have their own. Place this line in the file:

alias ls='ls -F --color' 

or

alias ls='ls -Fa --color' 

The latter will display hidden files, which are those beginning with a period.

Of course you will need to use the vi text editor to do this -- see vi text editor (page xxx). I am presuming for now that you're working only at the commandline, not in KDE, so you don't have access to the nice graphical text editors such as KEdit. vi is a simple Unix editor.

Please be clear that .bashrc is "your very own version of AUTOEXEC.BAT", and every other user, including the superuser, will have their own. It is in your home directory, which in my case is /home/bkauler/. Incidentally, the "~" character also denotes your home directory, as is further clarified below, so I can say that ~/.bashrc is the location of my personal .bashrc file.

If you want the effect to be global, that is, you want the alias command as above to apply to all users, then you will need to place the command into /etc/bashrc. However, you will need to login as superuser to be able to edit this file.

That's an interesting point about hidden files. It is standard Unix practice to name a file with a leading period to make it hidden. So, the ls* command will not normally display it. There should be some hidden files in your home directory (.bashrc is already mentioned above). Do this:

$ cd ~
$ ls -Fa --color

You can try it without the -a option to verify that the hidden files are not displayed.

The reason that they are hidden is that Linux does not want you to mess around with them! At least, not in your normal day-to-day use of the PC.

Files listed with "*" postfix are executables, "/" are subdirectories, and "@" are links. No postfix means the file is a text file. Note however, that there is a little trap here -- a text file could be what is known as a script, and be marked as an executable. A script will be postfixed with a "*".

If you would like to see some text files that are scripts, and thus executables, do this:

$ cd /etc/rc.d/init.d
$ ls -l

There should be a file there called crond*. Note that Linux has the more* command, just like MSDOS, and if the ls* command has displayed more than a screenful, you can do this:

$ ls -l | more

To verify that crond* is actually a text file, type this:

$ pr crond | more

Pressing the <space> key will display the next windowful, and pressing the <q> key will terminate the pr* (print to standard output, which by default is the screen) command.

I guess that to round off this section I should list many of the switches or options that can be used with the ls* command:

"What is an inode?" I hear you ask. Look at Linking files (page xxx).

Manipulating files and directories

Well, remember that Linux is very powerful, and I can't cover everything in this book. Hopefully though, I will have picked out just what you need to be up and running and a reasonably competent user.  Commands covered in this section:

Further help on these commands is available from the manpages. For example:

$ man echo

A major deviation from MSDOS and MSWindows is that Linux is case sensitive. the file xf86config is different from XF86Config. yes, there are actually two files with these names in Linux. So, be careful. This difference even shows up on the Internet. Linux and Unix systems are popular as Web servers, as is MSWindows NT. But, they handle URLs differently. http://www.arrow.com/customers/brubble/ and http://www.arrow.com/customers/BRubble/ are treated as identical by the MSWindows NT server, but as different by the Linux/Unix servers. Therefore, as you usually don't know what server you're dealing with, always be careful to type in a URL with the correct case.

Getting around the directories in Linux is similar to MSDOS:

$ cd /home/bkauler
$ cd ~
$ cd

These three all do the same thing! (assuming we are logged in with username bkauler). ~ is shorthand for your home directory, and just cd on its own is also a shorthand way of getting home.

If the prompt does not show the full path of your current directory, type this:

$ pwd
/home

pwd means "print working directory", and in this example is /home/. In that case:

$ cd bkauler
$ cd ..

The first example changes to /home/bkauler/, except that the full path does not need to be specified. The second example goes up-one, so the current directory becomes / (if the current directory was /home/), i.e., the root directory.

If you want to make (create) a directory, say /mnt/cdrive/:

$ cd /mnt
$ mkdir cdrive

If you want to remove an empty directory:

$ cd /mnt
$ rm cdrive

If you want to quickly create an empty text file:

$ touch temp1.txt

To delete a file:

$ rm temp1.txt

A file may also be copied to another directory. Assuming that we hadn't deleted temp1.txt, and we are still in the directory containing temp1.txt:

$ cp temp1.txt /tmp

That is, it's in the form cp [path]sourcefilename path[destinationfilename], with paths if required. As usual, the square brackets indicate optional components. The destination filename is only required if different from the source filename.

Another useful thing to know about, is the Linux search path. MSDOS has the same thing. Whenever you type the name of an executable file, such as rm* above, Linux will search for it. This is how you see the search path:

$ echo $PATH

/opt/kde/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/bkauler/bin

If you had an executable file, and you wanted to put it somewhere so it is in the search path, which of these directories would you choose?

This is where you need to be aware of directory permissions, as described in File and directory permissions (page xxx).

/bin/ directory can only be written to by the superuser, but anyone can read and execute what is in there. Probably you will find /usr/bin/ is setup the same way. The latter is a common place to put an executable, and every other user will be able to execute it, but you'll have to login as superuser to place it there.

Ok, rm* is an executable, and is somewhere in the search path, but where is it specifically? Often you will want to find a file, and there is an appropriate command:

$ find / -name 'rm'
 /bin/rm

This will search the entire directory hierarchy, looking for rm*, and will find all occurrences. The format of this command is find [path] [expression], where -name is an example of what can be placed in the expression. See the manpages for more details. The [path] specifies where the search starts from, and if left out the search will be from the current directory downwards. One option that I do find useful is this:

$ cd /opt/kde
$ find -name 'kppp' -maxdepth 4

The -maxdepth option specifies how deep (i.e., how many levels) into the directory structure to search, from the [path] (or current directory) starting point.

WARNING WILL ROBINSON, WARNING!
Say that you want to execute rm* but it is not in the search path, and is in the current directory? This is a major divergence from MSDOS. MSDOS will look in the current directory first, then in the search path. Linux will not look in the current directory.

Say that you have an executable, myexecutable*, and you have placed it in /home/brubble/mywork/myexecutable*. If this is also the current directory, this will not work:

$ cd /home/brubble/mywork
$ myexecutable

To execute it you have to specify the path, and either of these will work:

$ /home/brubble/mywork/myexecutable
$ ./myexecutable

The single period means "the current directory". A double-period means "one directory up". MSDOS has the same naming system.

There's so much more, but this will get you off and running. Actually, there's no need to master all the intricacies of the commandline, as once inside KDE you'll find that you can do most things in a more intuitive way.

Linking files

xxx -- include inodes

Users and passwords

When you are logged in as superuser, you can create new ordinary users by the useradd* program. This is introduced in Chapter 1, Adding a user account, (page xxx). You will assign them a username and a password.

Some years ago, the in-vogue advice was to change your password frequently. The problem was that people then had to write the latest password down on a piece of paper somewhere, as they couldn't remember it, which seriously compromised security. Every time I received this advice at work, I just thought to myself, "The idiots", and kept my old password. Except that one of the systems I used was setup so that it insisted that I change my password every month -- fortunately, it didn't complain if I typed into the "New password" field the same password as the old one.

The point is, choose a password that no one will guess, memorise it, and stick with it for sometime. Prefereably more than six characters.

If you do want to change your password, this is how:

$ passwd [username]
Current Unix password: xxxxxxxx
New Unix password: yyyyyyyy
Confirm new Unix password: yyyyyyyy

Do not type the part in square brackets. You just type "passwd" at the prompt and hit the <enter> key. Then, you do what the prompts ask.

The superuser has the power to change anybodies password, which can be a lifesaver. As user bkauler if I have forgotten my password, I can ask the superuser (which on this workstation is me also!) to give me a new one. This is where that part in square brackets comes in. The superuser can type:

# passwd bkauler
New Unix password: zzzzzzzz
Confirm new Unix password: zzzzzzzz

And can then assign a new password.

Incidentally, where are these passwords stored? They are in the file /etc/passwd, and in most Linux distributions this file is read-only for ordinary users. Fortunately the password is stored in an encrypted form.

vi text editor

You may have been referred here from one of the preceeding chapters. You have just got Linux installed, you're a "newbie" and haven't a clue how to run an editor, and maybe not much of an idea how to navigate around the directories. But, if you know MSDOS, you've got a head start. Study the rest of this chapter to fill in the gaps. If however, you just want to see how to drive the vi editor, then get back to business in Chapters 1 or 2, this little section is what you need.

An example is to edit the XF86Config text file. Firstly, you need to change to the directory in which it is located, using cd* (familiar?). Then you can start vi:

# cd /etc/X11
# vi XF86Config

The vi editor is one of the Unix character mode editors, and is somewhat crude compared with the nice graphical interfaces that you are accustomed to. When you first start it, vi is in what is called command mode. To make changes to the text you have to enter edit mode. In command mode, as the name suggests, you can enter various commands. These are the absolute most basic commands in command mode:

You get out of edit mode, back to command mode, by pressing the <esc> key. The commands shown here are to be typed exactly as shown, including the leading ":". When in command mode, you don't have to worry about where the cursor is when you type one of these commands.

There are more commands, but this is enough to get you up and running with vi, and is probably all you'll need, as your purpose is just to do some basic editing. Once you get KDE installed you'll have nice graphical editors to use.

File and directory permissions

These are the commands introduced in this section:

This is one of the heavy duty features of Linux, showing its Unix bloodline. It is designed for multiple users, and each user can be protected from the others. Your kids can play games and go onto the Internet, but they can't erase your sensitive files. In fact, you can give various types of permissions. You could for example allow the kids to enter a directory and view the files therein, but not change anything. Or, you could keep them out of the directory entirely. You could let them open a text file, but not change it. To execute an application but not delete or change it.

Let's say that you had an executable, say myexecutable*, in your home directory, and let's call you brubble. say that you want to place this file into /usr/bin/, for all to use:

$ cd /home/brubble
$ cp myexecutable /usr/bin

It won't work; a "Permission denied" message will display. So, what's wrong? Do this:

$ cd /usr
$ ls -l

Figure 3.1 shows what will display.

Figure 3.1: Directory permissions.

File permissions

Let's examine the information displayed about /usr/bin/ directory (for now, don't worry about the fact that /usr/bin/ is a directory rather than a file):

drwxr-xr-x 2 root root 16384 May 16 1999 bin/
drwxr-xr-x             These are the permissions for this directory.
d                      This declares it as a directory, not a file.
 rwx                   r=read, w=write, x=execute, permissions for owner.
    r-x                Read, write, execute permissions for the group.
       r-x             Read, write, execute permissions for everyone else.
            root       Name of owner.
                 root  Name of group.

Every file and directory has these permissions. There are three different classifications of people here; the owner, a group, and everyone else (others). Someone has to own a file or directory. It could be a user, such as bkauler, or the root or superuser, with the username of root. Users can be grouped together, into groups, and each group can be given a name. Groups are perhaps a little bit beyond this simple introduction -- if you want to know more about creating and managing groups, read a deeper systems-level book such as Mastering Linux published by Sybex.

However, I have made some further notes on groups, and a simple hands-on exercise, in Hardware permissions (page xxx).

What we are seeing here for /usr/bin/, is that the owner (root) has read, write, and execute permission, the group (named root also) has only read and execute permission, while everyone else (which would normally mean all the ordinary users) have only read and execute permission.

However, we need to be careful how we interprete those words "read", "write" and "execute", with regard to directories. With files it is straightforward:

Text file
An ordinary text file would have read and/or write attributes set, but it would definitely not have the execute attribute set.

Executable
An executable, which includes a text file script, would have execute attribute set, and maybe the read or write attributes.

One thing you will find quite common is for a file to only have the write attribute set for the owner. Obviously, we don't normally want people other than the owner to modify it!

So, although I have given the example above of looking at the permissions of a directory, I've only discussed them in terms of a file. Summarising these permissions with regard to a file:

"Read"
This means that a file can be read, i.e., you could use a text editor to open the file for reading.

"Write"
This means that a file can be written-to, i.e., you can edit the file in the text editor and save changes.

"Execute"
This means that if the file is an executable, you are allowed to execute it.

Directory permissions

Anyway, back on-track with how read, write and execute have to be interpreted for the case of directories. Figure 3.2 is a snapshot of a window inside Kfm, KDE's file manager.

Figure 3.2: Directory permissions.

I obtained this window by right-clicking on the /usr/bin/ directory icon inside Kfm, and choosing Properties. The same permission information is presented here, but notice the headings for the columns:

"read"
This column is really asking if the files in this directory can be shown, or displayed.

"write"
This column is really asking if it is allowed to store files in this directory.

"execute"
This column is asking if it is allowed to change into this directory.

What you can see here is that ordinary users are allowed to see the files (and directories) inside /usr/bin/, but they are not allowed to store anything there. If the "execute" entry had not been set, the users would not even be allowed to go into that directory to see what's there.

The owner of a file or directory can change these permissions. The superuser can too; he/she has power over everyone else! In the case of /usr/bin/, it is owned by the superuser, so only the superuser can change the permissions. This is done by the chmod* command. Let's say that we want to let anyone store files into this directory. So, what we want is permissions that look like this: rwxrwxrwx. That is giving the group write access also, which we might as well do, since everyone is getting it. This is how we can do it:

# cd /usr
# chmod 777 bin

You need to understand the octal number system here! 777 actually means binary 111111111. That is, each digital, in this case 7, is the octal (and in fact the decimal) number of the three-bit binary value, in this case 111.

Another example. Say that I don't want anyone to write to the directory, and I don't want anyone to change into it either:

# cd /usr
# chmod 744 bin

The octal/decimal digit 4 is binary 100, meaning that the group and others have only read permission. Get the idea? By the way, if you do mess around with the permissions of /usr/bin/, it is best if you change them back to what they were when you've finished.

Of course, inside KDE's Kfm, you just tick boxes to do the same thing, as per the above figure.

There's a little problem that sometimes comes up. You may have created a file while logged in as root (say), but you really intended that a normal user, say bkauler, should be the owner. Yes, there is a command for reassigning ownership; it is chown*. You can use the manpages to find out more about chown*, but I have used it further on in this section to illustrate usage.

Now here is something interesting. Figure 3.3 is a snapshot of my home directory.

Figure 3.3: Locked directories.

Notice that two of these directories (the modern word is folders!) have a strap around them. This means that they are locked, which actually means that the execute attribute is clear. That is, I cannot see inside these directories.

The interesting thing about this is who owns these directories. I am the owner of BKtemp4/, which occurred by default as I created the directory. What I did to modify the permissions was to right-click on the BKtemp4/ icon. I unchecked the owners change-into or execute field. Presto, I can't get into my own directory! I did this just to demonstrate, and I can easily unlock it, as I am the owner. As owner of the directory, I have the right to change permissions any way I want. So, logged in as bkauler, I can restore execute (change-into) permission to /home/bkauler/BKtemp4/:

$ cd /home/bkauler
$ chmod 700 BKtemp4

Now look at the figure again. There is a directory BKdownloaded/ which is also locked. I created this when I was downloading files off the Internet, and at the time I was logged in as root. It was actually a bit of thoughtlessness on my part, as this directory is by default owned by root. Creating it in bkauler's home directory was inappropriate. Well, to fix things, I want to unlock it so bkauler can also get into it.

The only way that I can change the permissions of a file or directory owned by root is to login as root. However, there is a quick way to do this; by means of the su* command. This command starts a shell with root privilege:

$ su
password: xxxxxxx
#

You can see that you are root because of the # prompt, but there is a command that tells you who you are:

# whoami
root
#

As root, I can now modify the permissions for /home/bkauler/BKdownloaded/:

# cd /home/bkauler
# chown -R bkauler: BKdownloaded

chown* is the command to change ownership of a file or directory. the option -R turns on recursion, which means that all subdirectories and their contents will also be changed. The option bkauler: specifies the required owner, and the trailing colon followed by a space specifies that all files in the directory will be changed to the new owner also, and also the group will be changed to the new owner's default group. Finally there is the name of the file or directory.

Problem fixed. Except that you should immediately exit from the root privilege level:

# exit
$

Hardware permissions

Another common problem is with the permissions of hardware devices. Recall that Linux treats all hardware devices as files, and you will find these in /dev/. It could be an actual device, such as a floppy drive (fd0 for example), or an interface, such as a serial port (ttyS0 for example). Let's have a quick look at /dev/fd0, the first floppy disk drive:

$ ls -l /dev/fd0
brw-rw-r-- 1 root floppy 2, 0 May 6 1998 /dev/fd0

The letter b designates this as a block mode hardware device. The other possibility is the letter c, which designates a character mode hardware device. From the user's point of view, there is no difference between b or c.

It's owned by root, which is ok, but notice that ordinary users only have read access. Hmmm. Aah, but the floppy group has read and write access! Question is, who is in this floppy group? To see who is in the groups, view the contents of the text file /etc/group. An examination of the file shows that nobody belongs to the floppy group (see further in this section for a printout of /etc/group).

Yet, I can do this:

$ mount /dev/fd0

(Or, inside KDE you can create an icon for the floppy drive and just left-click on it)

And then I can read and write from and to the floppy disk, as user bkauler.

I can mount the floppy drive alright because of what is contained in the text file /etc/fstab, which actually overrides the permissions of /dev/fd0.

/etc/fstab is described in Mounting a drive (page xxx), and you can see there the example file content, in which /dev/fd0 has the user qualifier. user specifies that anyone can mount the floppy.

However, once mounted, the permissions of /dev/fd0 seem to indicate that users other than root and group can only read from the drive. No, because once mounted, the permissions of /mnt/floppy/ apply. This is a tricky point, because it really doesn't matter what permissions you set the other-user rwx fields of /dev/fd0 to! Yet, in other situations it may matter.

I'm reminded of the CDROM drive. You can see in the example listing of /etc/fstab that /dev/cdrom also has the user qualifier. This means that anyone can mount the CDROM drive, but the ro qualifier means they can only read from it. Here are the permissions:

lrwxrwxrwx 1 root root 3 Mar 12    1999 /dev/cdrom -> hdb
brw-rw-r-- 1 root disk 3, 64 May 6 1998 /dev/hdb
drwxrwxr-x 2 root root 1024 Oct 10 1998 /mnt/cdrom/

Notice that /dev/cdrom is preceded by the letter l. This designates it as a link, which simply means that the name /dev/cdrom is just an alias for the real name, which is /dev/hdb.

Links are covered in linking files (page xxx).

All of these different permissions are very interesting! (you may have a stronger word to apply here)

The main point I want to make here is that programs will access a hardware device in different ways.

I'm thinking of a CD player that I installed some time ago, that wouldn't work (a KDE application). The CDROM was required to be unmounted before executing the CD player program. In other words, don't run the mount command (or left-click on the CDROM icon in KDE). The CD player communicates directly with the CDROM interface and does it's own mounting and unmounting.

Therefore, the permissions of /dev/hdb must be set right. The permissions of /dev/hdb were originally (when the system was first installed):

brw-rw---- 1 root disk 3, 64 May 6 1998 /dev/hdb

An examination of /etc/group file shows that group disk only has one member, which is root. So, only root has read and write access.

The problem was that I was logged in as an ordinary user. So, I had to login as root and change the permissions to as shown earlier, so all users have read access. Of course, I could have edited /etc/group and placed bkauler as a member of disk group, but I wanted anyone to be able to read the CDROM.
This is a problem that you may come across sometimes.

In fact, I might as well give you another example. I just remembered another KDE application that doesn't work; KFloppy, the floppy disk formater. At least, on the Red Hat system I'm currently using it doesn't. When I try to format a floppy disk, I get the error message "Cannot access /dev/fd0H1440". I know how to fix this, but I've been too lazy.

I'll fix it right now, and use it as another hands-on lesson. Have a look at Figure 3.4.

Figure 3.4: Floppy disk device files.

What you can see here is that there is not just the generic fd0, but device files for disks of specific capacity. KFloppy uses whichever of these specific device files is required to format the disk. As I only ever want to format a 3.5 inch 1.44M floppy disk, only fd0H1440 is of interest to me.

As you can see, the ordinary user does not have write access to fd0H1440. The most sweeping solution to this would be to add my username bkauler to the floppy group in /etc/group. A piecemeal solution is just to use chmod* to change the permissions of fd0H1440. Well, as I've already demonstrated the latter a couple of times above, let's now mess around with groups.

Here is a printout of /etc/group:

root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root   The IDE & SCSI drives are all in this group.
lp::7:daemon,lp
mem::8:
kmem::9:
wheel::10:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:
games::20:
gopher::30:
dip::40:
ftp::50:
nobody::99:
users::100:
floppy:x:19:       The floppy drives are all in this group.
pppusers:x:230:
popusers:x:231:
slipusers:x:232:
bkauler:x:500:          I even have my own group.

The first name on a line is the group name, and the comma-separated names on the end of each lines are the members of the group. There are four fields on each line, and the second field is an optional password, the third field the Group ID (GID).

I might as well put myself into the disk group as well, which kind of superceeds the piecemeal approach I demonstrated earlier, of giving every user read, write and maybe execute rights. Really, it depends on your setup. In a standalone workstation type of setup, you may be happy to just give anyone access to the various drives. In a more carefully controlled situation you may prefer to explicitly add certain people to a group. Anyway, here are my modifications to /etc/group (you can only do this as superuser):

disk::6:root,bkauler
floppy:x:19:bkauler

After making these changes, I have to logout, as Linux only reads /etc/group file when I login. Ok, I've done it, and I'm back here -- now I fire up KFloppy, insert a disk, and try to format it ... yep, she works!

(c) Copyright Barry Kauler 2000. All rights reserved.
Extract from book Linux for me, to be published sometime.
Main page: http://www.crosswinds.net/~goosee/ or http://www.goosee.com/ or http://goosee.net/