The first thing to learn is that everything on the disk is a file. There are just different types of files on the filesystem. There are directories, sockets, links, pipes, devices, and normal files. We won't be talking about sockets, pipes and devices here because those are too advanced and rarely used by anyone other than the most advanced programmers or system administrators.
mkdir [directory] | Makes a directory with the specified name. |
rmdir [directory] | Removes a directory with the specified name. Only works on empty directories. |
cd [directory] | Allows you to change into that directory, so that you can operate on the files in that directory. There are two 'special' directories in every directory, and they are '.' and '..'. '.' represents the current directory, so 'cd .' takes you nowhere. '..' represents the parent directory of the current directory. This means that if you are in '/home/personal/kelly/src/project1/' and you want to go to '/home/personal/kelly/src/', you can do 'cd ..'. If you type 'cd' with no arguments, you will be taken back to your home directory. |
Normal Files:
Normal files (called 'files' hereafter) make up a vast majority of the
contents of a filesystem. A file can consist of a library, a text file, a
shell script, source code, or just about anything else imaginable. There
are five main things to remember about each file: owner, group owner,
permissions, path, and filename.
Each file is owned by two different entities. The first is tied to a user
account. In your case, each file will be owned by 'kelly' (your unix
account). The second entity that owns files is the group. In your case,
most of the files will be owned by 'users' which is a collection of all
of the users on the system.
What keeps other 'users' from modifying your files? The permissions.
There are three sets of permissions for each file. One is for the user
(e.g.: 'kelly'), one is for the group (e.g.: 'users'), and the last
is for everyone else (the world, or others.) Each set of permissions
contains three basics sets of information: read, write, and execute. This
means that you can set 'kelly' to read and write a file, while 'users'
only gets to read the file, and everyone else gets no permissions at all.
Here's a sample directory listing:
-rwxr-x--- 1 zeavon spear 1531 Jan 11 14:40 autospear
drwxr-xr-x 2 zeavon spear 4096 Jan 11 14:51 bin/
drwxr-xr-x 4 zeavon spear 4096 Dec 29 23:39 log/
-rwxr-x--- 1 zeavon spear 406 Feb 24 2003 postboot
-rw-r--r-- 1 zeavon spear 47 Jan 11 14:55 syslog
The first 10 columns tells us what kind of file the entry is and what its
permissions are. The first column tells what kind of file it is. If there
is a 'd' there, it's a directory. If there is a '-' there, then it is a
file. There are other characters that can be in there as well, but we'll
not cover them here.
The next three columns tell us the permissions that the owner 'zeavon'
has. If there is a 'r', then zeavon can read the file. If there is a 'w',
then zeavon can write to the file. If there is an 'x', then zeavon can
execute the file. In this case, 'zeavon' can read, write, and execute
everything in there, except for 'syslog'. This is because 'autospear',
and 'postboot' are scripts to be run, and 'syslog' is just a normal text
file.
The next three columns tell us the permissions that the group 'spear'
has. The same rules apply here. According to the output, the 'spear'
group can read everything, can write to nothing, and can only excecute
'autospear', 'postboot', and the directories 'bin' and 'log' (see the
note below on how the execute bit affects directories.)
The next three columns tell us how everyone else can access the files.
The same rules apply here. The world has read and execute permissions
on 'bin' and 'log', and read permissions on 'syslog', but nothing else.
That means that the 'kelly' account could see the contents of 'syslog',
but not modify them. The 'kelly' account also could not even view the
contents of 'autospear' or 'postboot', and 'kelly' could certainly not
execute those scripts.
NOTE: If a directory has an execute bit, that means that the
person with the permissions could 'cd' to that directory, but it does
not allow them to change anything in that directory unless they also
had the write permission as well. If the execute bit is missing for a
user/group/world, then they are totally locked out of it. If you end up
with a directory that you cannot 'cd' to, but you think you should be
able to, check the execute bit.
NOTE 2:: Windows determines if a file is executable by its
extension (the part after the '.' in the filename.) This is not true
of Linux. Just because something is named 'runme.exe' does not mean
that Linux will run it. You can take a file named 'willnotrun.txt' and
do a 'chmod u+x willnotrun.txt' on the file, and suddenly it become
executable. However, this does not mean that it will run properly unless
it is a binary file or a properly built shell script. When you create a
new binary (e.g.: fpc program.pas) the resulting binary file (program)
will not be executable (unless the compiler does it for you) until you
perform a 'chmod u+x program' on the file.
Last Modified: 2006-04-19