an update to newbie.txt

Nathan Ladd nathanladd at
Thu Oct 3 09:45:36 PDT 2002

DJ Lucas wrote:

> "nathan ladd" <nathanladd at> wrote in message
>> makedir:
>> This creates a new directory.
> umm...probably "mkdir" would be better ;-) (same as in DOS)
> DJ

Whups--sent the wrong one.

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 

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 

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. T o 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 

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 

Another thing: do not suffer from the "I'll reinstall, it'll probably work 
this time" syndrome.  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.  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 paper clips--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."  The key is 
patience, persistence, and self-reliance.


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 all over the net.  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" P.O.S.

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 PREFIX= option, which is used heavily in LFS and BLFS (see RESOURCES).  
It lets you configure where you want the package binaries (like .EXE in 
Windows) 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 


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 /etc/issue.

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!

The following files are covered in the BLFS book
/etc/issue      Customizes your login prompt
                Your login prompt is what gets displayed before you type in
                your user name/pass.
/etc/profile    LFS (and all Linux distros) use bash as the shell (like
                COMMAND.COM in DOS).  This file customizes bash.
/etc/inputrc    The keys you press like control, alt, backspace, etc., all get
                interpreted by the shell according to this file.
/etc/vimrc      This is the configuration file for vim, your friendly UNIX text

/etc/inittab    The program init handles booting and shutting down.  When the
                kernel is finished loading, it always looks for and runs a
                program called init.  init runs bootscripts and then starts
                virtual consoles that in turn use the /etc/issue file to
                display a login prompt.

                inittab can be configured to use more than six consoles, and
                you can even run console applications in their own terminal!
                There is a great hint for this file.
/etc/rc.d/*     The bootscripts go here; there is an excellent explanation of
                how they work in the LFS book.
/etc/X11/       Your X configuration file will sit here.  There are other
  XF86Config    config files that live in this directory for things like font
                rendering.  Be sure to check relevant manpages.


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 KDE/GNOME and go back to a GUI.

There's always that excellent Google search engine if you can't find help at, the man page stinks, or BLFS/hints have no info. 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 
MP3z ;)
Unsubscribe: send email to listar at
and put 'unsubscribe hints' in the subject header of the message

More information about the hints mailing list