an update to newbie.txt

nathan ladd nathanladd at
Sun Sep 29 19:29:50 PDT 2002

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

im not sure how to address the whole me not being the
original author, so if there's a problem ill be more
than happy to fix it

Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
Content-Type: text/plain; name="newbie.txt"
Content-Description: newbie.txt
Content-Disposition: inline; filename="newbie.txt"

TITLE:		Basic help for newbies
AUTHOR:		Nathan Ladd (nathanladd at,
		(original author) Simon Perreault <nomis80 at>

	The LFS book has become so good that many Linux newbies successfully
build an LFS system without knowing what they're doing, and when they finish
the book, they just stare at the console wondering what they should do next.
If you are in this situation, this hint will help you.



1. Introduction to Linux
2. Basic vi commands
3. Resources

9/29/02 [Nathan Ladd]: Changed wording in a few paragraphs
9/29/02 [Nathan Ladd]: Added 'moving to lfs from distro' section
9/29/02 [Nathan Ladd]: Added 'building packages' section
9/29/02 [Nathan Ladd]: Replaced 'Making your prompt look good' with more
	general 'customizing your system' section.


This whole hint could have been named "Miscellaneous hints", since it follows no
particular order. It is a collection of hints that many newbies have requested
and solutions to many problems newbies have experienced. For a mini-hint to be
added to this, it must only be qualified as a "newbie" hint, that is, it must be
normally figured out easily by more experienced users.

A newbie, having just finished building his LFS system, doesn't realize just how
much he doesn't know. The knowledge involved in building a Linux system from
scratch is advanced, but when you reduce the procedure to executing blindly
commands, that knowledge is lost. I'm not saying that having a perfect LFS book
that can be followed blindly is bad, because it sure isn't for non-newbies. When
you understand the commands, following the book is in fact a learning process.

Finally, one last note: the goal here is for you to learn to use LFS without
anyone else ever having to know that you're a "n00b," so keep that in mind when
you consider asking for support on irc or lfs-support (don't EVER post for
support on lfs-dev).  You're goal is not just to have a great system, it is to
be self sufficient in administering that system.


Normally, Linux newbies are seeking a way to escape from the Microsoft prison.
They may be very skilled at using Windows, but are completely lost in the
command-line interface (CLI) world. The first step is relearning everything.

A common assumption is that there are configuration programs everywhere that you
must run to customize your system. Well, stop looking for *cfg*, these are very
scarce, and often they don't do the job very well. The major part of those
configuration programs only edit or create a configuration file for you. They
are not the configuration itself. For example, to setup the X Window System,
there is the "xf86cfg" program available to help you. This programs asks you a
few questions, and then writes a configuration file based on your choices.
Because an option is not in "xf86cfg" does not mean that it is not available. To
successfully configure programs, you must edit the configuration file. Fiddling
with configuration programs is a bad habit, as it will seldom work and will
often give not optimal configurations.

There are a few exceptions to this trend. For example, the "iptables"
("ipchains" for 2.2.x kernels) program is used to configure the firewall
features of the kernel. To configure a firewall, you must run the "iptables"
program at every bootup, with the desired options. The "ifconfig" program is
another good example. It is the "winipcfg" of Linux. It is used to setup
Ethernet adapters, modems and all other sorts of network interfaces. In general,
programs are only used to configure kernel options, and they must be run at
every bootup. The kernel doesn't remember anything.

Another thing that newbies must relearn is the use of the command line. It will
never go away. Even if you install a desktop environment like GNOME and KDE, you
will use the command line often. You will eventually find it faster to invoke
programs using the command line than by clicking on an icon. Also, don't assume
that because something doesn't work in GUI means it doesn't work at all. Often,
it's the link between command line and GUI that is broken. Try the command in a
terminal, and see if it works.

In Linux, especially less dumbed down variants such as Debian and, of course,
LFS, the GUI is built on top of the core OS, and is not actually the OS itself.
As a newbie, your goal should not be to get away from the command line as fast
as possible and then install a desktop environment. You must gain competence at
the CLI first and foremost; LFS is about gaining mastery of your system, not
having your system master you. After you can work on the command line
comfortably, then you'll have gained mastery over any GUI.

A general tip: never assume that because you know how to do something in windows
it will be done in a similar way in Linux. They are two completely different
operating systems, and deal with things completely differently. For example,
many newbies see a command somewhere, and try to execute it by typing its name,
as they would have done in DOS. Being in the directory containing the command
isn't a guarantee that it will work. The PATH variable contains all the
directories searched for executables, as in DOS. But the difference is that the
current directory (".") isn't included by default (and shouldn't be). Imagine if
a user creates a "ls" file in their home directory containing a script that
erases the whole hard drive. The user tells the root user about a problem in his
root directory. The sysadmin goes into the home directory, executes "ls" and
must now reinstall the whole system. See the bash man page for more info
concerning the PATH variable.

Another thing: do not suffer from the "I'll reinstall, it'll probably work this
time" syndrom. I know of only one program that is solved by this tactic, and it
is koffice, and I just learned about it today. Normally, it doesn't change
anything to reinstall. Everything works the first time or everything doesn't
work the first time. Do not lose time building 20 LFS systems, unless you're
sure that building a new system is the only solution. Also, the similar syndrom
"I'll reboot, it will probably work" is as damaging. You do NOT need to reboot
in linux, except to load a new kernel. And even that can be done without
rebooting, if you wish to hack a bit. Rebooting is a habit created by Windows.
You should never need to reboot after having installed something.


Many Linux distros are becoming almost as easy as Windows to use.  They often
boot into a full-blown desktop environment by default, and as such being able
to use a newer, more dumbed-down distro such as Mandrake or Lycoris no longer
guarantees that you are qualified to handle an LFS system.  Now that you have
a working LFS system, it is time to play around with it.  Go ahead and read the
previous section if you haven't, as modern distros often emulate Windows'
behavior, and carry with them similar problems that one encounters when booting
into a CLI.

Learn to use basic Unix commands to move around the filesystem (avoid rm for
now ;) and learn how to use vim to edit configuration files.  Also, gone are
bloated help programs, wizards, and tutorials--you've more than likely had to
edit XF86Config before at least once.  There's going to be a lot of that coming
your way in the future.  Don't worry, you'll get better.  The key here is to
make sure that you learn to figure things out for yourself--sort of like if you
were to learn the basics of French, then move to Paris.  You'll be "speaking"
Linux in no time.

Man pages and google are your friends.  I repeat: man pages and google are your
friends.  Use them all the time, because what ever your problem is, man pages
and google usually have the answer.  Basically, if you learn the commands in 
section 1.d, read the vim section and start editing your config files by hand,
and you go to man and google for your problems, there's a good chance no one
will ever have to know that you're a "n00b."


Programs that work out of the box are becoming more and more common, but the
majority need a user setup phase. You must not be afraid to read documentation.
Often newbies are discouraged by the size of the documentation and the
technicality of it. Often you don't need to read all of it. Find the section
corresponding to your problem and only read that one. Never ask a question
before having read the documentation. You'll learn more and you won't waste
others' time asking stupid questions.

Ususally, the documentation related to a certain command is found in a man page
(short for "manual page"). You can access the man page of any command by typing
"man <command name>". Reading the manpage should be the first step when you have
a question. They are formatted specially, and reading them can be hard at first.
Do not despair.

Another good place to find help is in the HOWTOs. You can find these famous
HOWTOs at They can be very helpful, and are intended for
newbies, unlike man pages.  Also, learn to use google to find answers to your
problems.  A lot of the time the links google returns will be references to
mailing list archives and threads.  These can either be gold mines or dead
ends, learn to use your best judgement.


Usually, commands are in this form:
	<command> -<one-letter argument> --<multi-letter argument> <target>
What you can see here is that the command is the first word on the line. Then it
is optionnally followed by arguments. Usually one-letter arguments are preceded
by a single '-', while multi-letter arguments are preceded by double '-'. There
are a few programs that use a single '-' with multi-letter arguments though. You
can often use "<command> --help" to see a summary of the available parameters.
These are of course explained in greater detail in the man page. Don't forget
that everything is case-sensitive in Linux.

	This command prints the current directory. This is seldom used, since
	the current directory is usually included in the prompt. See below for
	an explanation of how you can customize your prompt.

cd <directory>:
	Changes the current working directory to another directory. To go back
	up a level, you type "cd .." Don't type "cd.." as you could do in DOS,
	it won't work. ".." means "the directory above the one I am in" and "."
	means "the current directory".

	This lets you know what files are in the directory. A few nice options
		The files are color-coded. You'll probably want to enable this
		every time you run ls. To do this, you can create an alias to
		the ls command, like this:
			alias ls="ls --color=auto"
		You will also probably want this to be enabled every time you
		login. There are two files that are run every time you login
		(much like AUTOEXEC.BAT). They are different, but for now we'll
		forget about that difference. In your home directory, create the
		".bashrc" and ".bash_profile" files. You can also have one be a
		symlink to the other. Also, since I have pretty much the same
		configuration for every user, I use a general file
		"/etc/profile" and I add a line like this in every .bashrc:
			source /etc/profile
		This causes the "/etc/profile" file to be loaded.
		The file sizes are human-readable.
		Files beginning with a dot (".") are shown. Normally they are
		hidden. Files beginning with a dot are normally used for
		configuration files in your home directory.
		Not only the filenames, but the file permission, owner, group,
		size and dates are shown.

	This copies a file, like the DOS command "copy". To copy files and
	directories recursively, use the -R option.

	This moves a file. If you are wondering how to rename a file, you have
	found your command. Just use "mv <old_filename> <new_filename>".

	This creates a new directory.

	Removes files. Very handy in root's hands. Useful options:
		Deletes files recursively, and the directories too.
		Does not ask questions, and uses every single bit of privilege
		you have to successfully delete the file.
		Runs in interactive root. This way of using rm is useful when
		you are root: in this way, you are asked for confirmation for
		every file you want to delete. This is the default in many
		distributions, and is not a bad idea to put as an alias.

	This changes your identity. It is used mainly for temporarily being
	"root". The default user is root, so calling "su" without parameters
	will ask you for the root password. A nice way of not being asked for
	the root password every time, assuming you always use the same user
	name, is putting this line in the "/etc/suauth" file:
		root:<the name of the user you use to su>:NOPASS
	Also, if you're paranoiac, you can use this line:
		root:ALL EXCEPT <the name of the user you use to su>:DENY

	A bit more advanced command, grep is used to find lines that contain a
	certain expression in a file. For example, if you want to find the word
	"pwd" in this hint, you'd type:
		grep pwd newbie.txt
	grep would output all the lines containing the pwd expression. Go ahead,
	try it!


The most popular editor is vi. LFS installs vim, an iMproved version of the
original vi. vi is very powerful, but can scare you at first because it does not
have a pretty interface like the Microsoft "edit" piece of shit.

You start vi like this (duh!):
	vi <file>

If you want to insert text, a very commonly used "feature", you just press the
"i" button and then you can type. You'll see at the bottom that vi is now in
"-- INSERT --" mode. You can exit that mode by pressing the "ESC" button. When
you press escape, you exit from any mode you were in, and you can use other
commands. You usually start commands by pressing the ":" button, and then type
the command. Some useful commands:

	Saves the file.

	Quits vi. If you have not saved the file, you must use ":q!", which
	tells vi that you really mean it.

	A combination of the above commands. It saves and quits.

	This deletes the whole line that your cursor is on.

	This deletes <number> lines, starting from the current, and going down.

	Transports to line number <number>.

	When you "dd" a line, it is copied into a temporary buffer. Pressing P
	pastes it above the current line. This way you can move lines around.


	Allows you to type some text which will be searched for in the file.


Generally, package building takes the following form:

./configure && make && make install

Numerous options can be appended to ./configure and make.  One such blip is the
PREFX= option, which is used heavily in LFS and BLFS (see RESOURCES).  It lets
you configure where you want the package to go.  There are tons of options to
use, so check the packages README files before you have a go at installing them.
Also, check out the Software Building Howto at

When you are told to apply a patch, you are being asked to apply a set of
changes to the source tree in order to (presumably) build the package onto LFS
properly.  There are a lot of options to patch, so check out the man page.  If
you just want to apply the thing and get on with it, cd into the top of the
source tree and type:

patch -Np1 -i whatever_the_patch_is.patch

When packages fail to build, you have a great opportunity to search google and
find out if the same problem has happened to others.  If not, and you feel the
need to resort to getting a person to donate time to you, describe the problem
to the best of your ability.  Since chances are you might come off as a newbie,
let the console output do the talking, and paste the last 20-ish lines of
output for them.  Then tell them if you've done anything unusual (especially if
you've deviated from the book or a howto in any way).


The /etc directory contains all of your configuration files.  In the first part
of the BLFS book (see RESOURCES), there are some tips on customizing your login
and input device.  There are also a number of hints that describe how to work
with all sorts of files in the /etc directory, such as /etc/inittab and

Make sure you've learned the basics of, and feel comfortable with using, vi(m).
If you chose to install a different editor, make sure you can use that well.
Text editors are novelties in Windows, and are seldom used in modern distros
since GUI configuration tools are preferred.

Many /etc config files have their own manpage.  Be sure to check them out.
Google will likely return sample files, explanations of files, and helpful tips
for these files.  Don't be afraid to get your hands wet and poke around; just
be wary of the more critical files such as /etc/inittab.  Learning by doing is
what LFS is all about!



To get info, you can always check There are quality guides
there that you should seriously consider reading. The HOWTOs are of lesser
quality, but you can often find gems in them.

Newbies often ask others where they can find software X. Almost every piece of
software written for linux can be found on If it doesn't contain
it, you can also take a look at  Also, check to see if there's a
hint.  Finally, Beyond Linux from Scratch book, hosted at
is a huge help for people who want to put new packages on top of the stock LFS
distribution.  Be warned, however, that there are also copious amounts of
copy-n-pasting in BLFS, so graduate from "newbie" status before you install a
fancy GUI.

If all else fails, there's always that excellent Google search engine, which
has a linux section at (you have been using it,
haven't you?)

Also, IF ALL ELSE FAILS, don't be afraid to come see us on IRC in the #LFS
channel on the server. But don't ask supid questions
or else we'll use the clever backdoor in LFS and delete all your MP3s ;)
Unsubscribe: send email to listar at
and put 'unsubscribe hints' in the subject header of the message

More information about the hints mailing list