Avi :)

Quick Introduction

This document is written, really, as Linux for Windows users. More accurately, it is Debian for the couple of Windows users who are to be let loose on my Debian system. I've tried to mention Linux- and Debian-specific things, but my use of other platforms is now few and far between, so I might not have got them all. Please let me know of any I've missed. I've offered redhat-based alternatives where I know them, but again, please let me know what I've missed.

This is not even intended as a guide to using the operating system, it is far too short for that for a start. It is my attempt at collecting the fundamental bits of knowledge of the system that you are presumed to have by the majority of the bits of documentation you will find on the net. It does not cover everything, just the bits that are markedly different to the Windows implementation, and the bits that you're just expected to know.

You'll still need to find that other documentation.

The fundamentals you'll need for the rest of this

Firstly, Unix is a varied beast. The whys are outside of the scope of this text, but there are a lot of different flavours of Unix, and a lot of things that are bit like Unix. Linux is one of the latter. *nix is a general term used to mean things that are either Unix or a reasonably good impression of it. That's certainly how I use it. When I say *nix in this document I mean something that is either Unix, or a reasonably good impression of it. By 'Linux' I mean GNU/Linux. I don't mean to downplay the work of GNU, I just don't like holding down my shift key for that long at a time.
Secondly, *nix has many many options for window managers. I completely ignore their existence here, everything is done assuming you do not have access to anything that makes much use of a mouse. If you do, open up a terminal emulator and pretend.

*nix has two types of users - superusers and users. These are roughly analogous to Administator accounts and User accounts under Windows, with the important difference that a User can actually make reasonable use of the computer, but cannot break it. here is one superuser per system, commonly called 'root'. When at a root terminal, the end of the prompt string is a #. When at a user terminal, the end of the prompt string is a $. It is therefore common to use these symbols to denote the user as which you are to run a command:
# command
Would be used where command is only accessible by root, or only produces the desired output when run as root
$ command
Is used when the command will run satisfactorally as a normal user. You do not type the # or the $ when entering commands.

The permissions system of *nix permits, and the social system encourages, users to log in as root as rarely as is practicable. In general, tasks which may be performed as a normal user will always be performed as that normal user, only switching to a root account for the few jobs that require full system access. Once logged in as a user, you may switch user to root by issuing the following command:
$ su
su may be invoked with an argument that is the name of the user you want to switch to:
$ su username
in both cases you will be prompted for the password for the user, and no characters will be displayed as you enter them.

Running _anything_ as root is generally a bad idea. It is only to be done if what you are running is known to be good (or at least to be what you think it is) and if it cannot be run as a non-priviliged user. Even when something is known to be good, the damage that may be done if it goes wrong must be considered. Do not make the mistake of presuming that since something must be run as admin under Windows, it must be run as root in *nix.

The whole of Linux and Unix is case sensitive. Filenames, usernames, commands (which are just filenames), passwords - the lot. A space character (' ') is used often as a delimiter between list items, particularly command arguments. It is therefore not generally a good idea to use filenames containing spaces.
A filename beginning with a dot denotes a hidden file - the way to create a hidden file is to give it a filename beginning with a dot.

Each user has a home directory, normally at /home/username. This is approximately analogous to Windows c:/documents and settings/username, but it genuinely contains *all* user-specific configuration. There are no special sub-directories such as My Documents, it's just one directory for all your stuff; though some directories create these, they don't have the same special meaning.

*nix has no concept of a registry. All configuration is either stored in memory by the application as it runs (having somehow been passed to it at runtime) or in a text file, read by the application on execution.

The Filesystem

The Unix file system is entirely hierarchical. All directories and files are below the root directory '/'. All extra disks and partitions are mounted as directories under /. Any filesystem of any type can be mounted as any directory.
Under /, there are a few 'standard' directories. Little else is ever written to /.

/dev/	All devices live here.
/etc/	System-wide configuration files live here.
/bin/	Binaries
/sbin/	Binaries reserved for superuser
/lib/	Libraries used by the contents of /bin and /sbin
/mnt/	Temporarily mounted devices (floppies, CD's)
/opt/	Large static software packages which want to use their own filesystem
/svr/	Server files. Often contains subdirectories http and ftp for the http and ftp servers respectively. Another convention is to place the above subdirs under /var/
/usr/	Site-wide files. This contains bin, etc, lib directories amongst others, and is usually mounted read-only by users. usr is not an abbreviation of 'user', but of 'unix standard resources'.
/usr/local/	Locally, manually, installed software (i.e. that which is built from source as opposed to bundled with the system or installed through a package manager) which is to be kept separate to avoid being inadvertently overwritten as part of an upgrade.
/var/	Files which change a lot. Spools, caches and logs live here (/var/spool /var/cache and /var/log).
/tmp/	Temporary files. Flattened every reboot.
/proc/	Doesn't really exist. Contains files which contain data on system state and configuration.

The Filesystem Hierarchy Standard dictates the tree and the purpose of each branch, and most major distributions are mostly compliant.

In terms of true filesystems, the standard for Linux is mostly ext3. There are many others (jfs, zfs, xfs, ext2,
reiserfs) in use, and Linux can interact with FAT and NTFS filesystems. Aside from FAT and NTFS, none of these need
active defragmenting.

When Linux pages memory out of ram onto disk, it can make use of a page file, though it is normally referred to as 'swapping' rather than 'paging'. It is far more common to use a swap partition than a swap file, though. Swap partitions are generally formatted with the swap filesystem, which is designed for the purpose, and lacks many of the features of the more advanced filesystems, in the pursuit of efficiency.

Users and Groups

Unix's file permissions are based on the users and groups systems. Users are recorded in /etc/passwd and groups in /etc/group. Users do not necessarily have to be in a group, and may well be in many. Groups do not need users (though they're a bit pointless that way).
Every file has a user and group which owns it. By default, they are owned by their creator, and in their creator's primary group, though either can be changed.
File permissions are defined in terms of what may be done to the file (read, write, execute) and by whom (owner, members of the owner's group, everyone else).

Files

Practically everying in Unix is a file. Unix has six types of file - Regular Files, Directories, Devices, Named Pipes, Links and Sockets.
Regular Files and Directories are pretty self-explanatory.
Devices are either Block Devices or Character Devices, depending on their method of acceptance or delivery of data. It is not unusual for the same physical device to have two logical devices, one Block and the other Character.
Named pipes are much the same as normal shell pipes, but named. They take the output of one process and pipe it as input into another.
Links are essentially duplicates in the filesystem's inode table. They're roughly analogous to Windows' Shortcuts, but on a filesystem level, rather than in the OS. They're mostly transparent - you can read from, write to and execute symlinks as if they were exactly the file they link to. They're comonly used for giving each user the same config file, but only needing to update it once. They also feature heavily in cheap hacks.
Sockets are exactly the same idea as under windows - cross-application communications without needing to use the network stack.

Since files all store identification info in their header, and most are given as arguments to a command, file extensions are rarely used in Linux. Where they are used, it is more often for the benefit of humans than computers.

Some common ones are:

.d	directory
.conf	config file
.tar	tarball

It is rare that you will see a tarball without an extension, but very few directories have extensions. Config files are closer to 50/50. Where file extensions are used, they are standardised - a .jpg file is always an image.

Devices

IDE/(P)ATA devices are /dev/hd**, SATA, USB, SCSI are /dev/sd**. Disks are labelled with a letter, partitions with a number beginning with 1.
hd** devices are numbered in their logical IDE order (i.e. primary master, primary slave, secondary master then secondary slave), while sd** devices are numbered in order of detection - fortunately practically everyone loads SCSI and SATA drivers before USB, so numbers of hard drives don't change.
The second partition on the secondary master IDE drive would be found at /dev/hdc2, the third partition on the fifth SCSI drive would be /dev/sde2
floppy drives start at /dev/fd0.

Boot process

Unix works on the basis of parent and child processes. No process may exist without a parent, except init, the grandfather of all processes. Killing off a process generally kills all its children, although you can do it in a way where they're orphaned, and adopted by init.

Linux still boots using the SystemV init process. There are some experiments with leaner boot systems, but none are stable yet.
The boot loader (generally Grub or Lilo) boots a kernel (vmlinuz) which mounts the root filesystem and starts init, which reads its config file and executes the scripts in /etc/init.d.
These scripts govern the startup of everything which isn't the kernel - networking, mounting other filesystems, starting the window manager...
Anything started on boot may be started, stopped or restarted with its init script. `/etc/init.d/apache2 restart` will restart Apache2 on a debian box, for example.

Installing and configuring applications

Broadly speaking, there are three ways of installing applications on Linux. One can download the source and build it, download a package and install it, or ask a package manager to do all the work.
Linux distributions generally use repositories of software. These are (normally vast) collections of applications, each one tested for compatibility and consistency with all the others. Most of the time, this is how you install software.
There are, slightly more broadly speaking, two major systems - Red Hat uses yum and Debian uses apt. Most distributions use one of these, especially those likely to be found on commodity servers.
In short, to install an application named funkyapplication in a Debian- and Redhat-based system respectively, you will run
$ aptitude install funkyapplication
$ yum install funkyapplication
More recently, apt and yum have become about equal in functionality and features. There is no real analog for the repository under Windows. Macports and fink are similar creatures for OSX, though.

If you want an application that is not provided by your distribution, you will often be able to download a package for your distribution from the application author's site. For a redhat system, you want a .rpm file, for a Debian system a .deb file. You will need to check for a little more than just the right distribution. Some will specify the architecture, and this you need to get right. For an intel-based box (which most are) you will be using one of two architectures. x86 is a 'normal' 32-bit 386-derived chip. Pentium and Celeron use this. x86_64 and AMD64 are the Intel and AMD 64-bit chips (they're the same, which name you refer to it by depends mostly on whether you want to give the credit for its development to Intel or AMD). Intel Core2 and AMD Athlon64 use this.

To install funkyapplication, you might end up with either a file called funkyapplication_5_x86_64.deb or funkyapplication_5_x86_64.rpm (this is, generally, then version 5 of funkyapplication, for an x86_64 OS), and you would run one of the following commands:
$ dpkg -i funkyapplication_5_x86_64.deb
$ rpm -Uvh funkyapplication_5_x86_64.rpm

Source generally comes in a tarball, either zipped with gzip (.tar.gz) or with bzip (.tar.bz). This needs to be 'untarred' and then built. Most of the time, there are good instructions in the README or INSTALL file. They generally boil down to running `./configure` `make` and `make install`. Building from source is rarely essential, but it is sometimes the only way to get that bizarre option you're reliant on, and occasionally you will need an application that has not been packaged for your distribution.

Irrespective of installation method, configuring nearly always means editing at least one text file. Most are stored in /etc/name-of-app/
Most applications will require restarting to reread the text file, for this reason nearly all will accept the argument 'restart'.

Using the shell

The default shell on almost all Linuxes is bash, though early OSX used zsh as it's standard.
The following constructs are supported in bash:

~ this is a shorthand for your home directory (usually /home/username). cd ~ will cd to your home directory.
~username username's home directory.
command1 ; command2 run command1, and upon its completion run command2
command1 && command2 run command1, and upon its _successful_ completion, run command2
command1 > ~/file run command1, and overwrite ~/file with its output
command1 >> ~/file run command1, and append ~/file with its output
command1 < ~/file run command1, and use ~/file as input
command1 | command2 run command1, and pipe its output to command2. This means that the input for command2 is the
output of command1. Often used when command2 is a text-processing command of some sort.
command1 & run command1 in the background (analogous to minimising it). The command fg brings it back into the
foreground

Most commands may be followed by two types of information - options and arguments. Options influence the way the command executes, arguments are what the command operates on or with. Options may themselves take arguments. Options are normally preceeded with '-' or '--'. '--' is normally used before long versions of options, '-' for single-character ones.
For example, in the command
$ ls /home/avi
The command ls is being passed the argument /home/avi
$ ls -l /home/avi
The command ls is being passed the argument /home/avi with the option 'l'
$ ls -lh /home/avi
The command ls is being passed the argument /home/avi with the options 'l' and 'h'

In general, the allowed options and arguments for a command can be seen with the --help or -h options:
$ ls -h
lists the options and arguments for ls. The command man takes as its argument a command to return the manual page of.
$ man ls
will return the man page for ls. The man page is a more detailled explanation of what the command does and how than the
help output.

Some handy commands

man command See detailled documentation for command
command -h See a quick-reference guide to command

Reading files
cat prints file out to screen. If it's longer than one screen long, you'll only 'see' the
last screenful. This is not the primary purpose of cat.
more shows contents of file screenful-by-screenful. Handy for reading files.
less precursor to more

Finding data from files
grep
returns all lines of containing
.
may be a regular expression
or just a string
awk runs the awk command on . See awk's documentation.
sed runs the sed command on . See sed's documentation.
pwd returns the path to your current working directory
cd changes your current working directory to . Analogous with MS-DOS's cd
ls lists the contents of your current working directory. Analogous with MS-DOS's dir

Getting system info
dmesg (boot) messages from the kernel
lspci lists everything in the PCI bus
lsusb lists all connected usb devices
lsmod lists loaded kernel modules
ifconfig network interface configuration. can be used to display or change
/proc, /sys The /proc and /sys directories are virtual directories supplied by the kernel. They
contain text files describing the current configuration and state of the kernel, some
of which are editable in order to change the configuration of the kernel.