On Wed, 27 Sep 2000 [EMAIL PROTECTED] wrote:
> I am fairly new to the Linux User Group ...

  Welcome, then!  :-)

> I have 4 different applications I downloaded from the net but am not sure
> how to get them up and running.
 
  What do the names of the packages you downloaded end in?

  Some formats you might see are:

   .tar      tar archive
   .tar.gz   tar archive compressed with GNU gzip
   .tgz      short for .tar.gz
   .tar.Z    tar archive compressed with Unix compress
   .zip      PKZip-compatible archive
   .rpm      Red Hat Package Manager
   .deb      Debian package tool
   .shar     shell archive (rare these days)

  What to do with a package depends on what kind it is.

> 1. What are the different ways to install (and uninstall) Linux programs?

  Generally speaking, packages are generally either managed or unmanaged.  

  MANAGED PACKAGES

  Managed packages are managed (surprise) by a program like Red Hat's RPM or
Debian's dpkg and apt tools.  The package manager keeps track of what has been
installed, and where, and also things like requirements and dependencies.  
The package manager is designed to automate the process of installing,
upgrading, and removing packages as a complete unit.

  For example, to install an RPM package contained in a file called
"foo-1.3-2.i386.rpm", you issue the command "rpm -i foo-1.3-2.i386.rpm" (the
"-i" stands for "install").  You may want to add a few more switches to see
what is going on.  You will see the idiom "rpm -ivh foo-1.3-2.i386.rpm" a lot;
the "-v" prints the name of each package as it is installed, and the "-h"
prints hash marks (#) as a progress indicator.

  One of the nice things about package managers is that you can install
several packages at once just by doing an "rpm -ivh *.rpm".

  To remove a package, you use "rpm -e package-name".

  To upgrade an already installed package, use "rpm -U new-version.rpm".

  The manual page for RPM (give the command "man rpm") is pretty good, and
very comprehensive.

  If you're not using RPM, similar rules apply.  The names will be different.

  UNMANAGED PACKAGES

  Unmanaged packages simply install themselves into wherever they want to be,
and after that they just sit on the filesystem unless you move or delete them.  
The package may provide a script or other automated install feature, or you
may be expected to copy the files into a directory yourself.

  Unmanaged packages are often distributed as source code.  Before you can use
the program, you have to build it.  The following sequence of commands is
almost idiomatic:

        tar -xzf foo-1.3.tar.gz
        cd foo-1.3
        ./configure
        make
        make install

  The first command unpacks the "foo" program, version 1.3, in the current
directory.  Such packages usually include a directory structure in the archive
based on the name of the program, so you change to that directory.  You then
run "configure", a script included by many programs (some simple programs may
skip this step).  "make" invokes a special kind of script (called a
"makefile", but that's another story for another time) which builds the
program.  Then "make install" actually copies the result to the appropriate
locations on your system so you can begin using them.

  Keep in mind that the above sequence of commands is only a prototype, and
generally should not be run blindly.  Most packages include an INSTALL or
README file explaining what you need to do.  Read it (them) first.

> And what do you prefer, recommend? Especially for Newbies.

  I generally prefer managed packages, simply because they make my life easier
overall.  As for the format: I prefer the format of the system I'm using.  :)  
When in Rome and all.  If I'm not looking at a distribution, well... RPM is
probably the most common, but Debian dpkg/apt has some additional features
that are Really Cool(TM).

> 2. Once installed (say with RPM) how do you know where the program
> installed itself?

  RPM has a query mode, which you invoke with the "-q" switch.

  "-l" will list all the files in an installed package.  For example, to see
what files package "rpm" owns, use "rpm -ql rpm".

  "-p" will let you query a package file, which is useful to get information
about a package before you install it.  For example, to list the files in the
original package which RPM came in: "rpm -qlp rpm-3.0.4-0.48.i386.rpm"

  "-f" will tell you what package (if any) a file belongs to.  For example,
you could do "rpm -qf /bin/rpm" to find out which package owns the RPM
program.

  "-i" will give you various information about a package.  For example, use
the command "rpm -qi rpm" to find out what RPM does.

  Again, see "man rpm" for more information.

> Also is there a preferred place to install Apps on a Linux box?

  Generally speaking, the package manager or install script will take care of
this for you.

  Briefly, the root directory (/) contains files vital to system operation,
/usr contains files installed with your distribution or under package
management, and /usr/local contains unmanaged packages you have installed
yourself.  bin contains user programs, sbin contains system programs, lib
contains libraries, and share contains platform-independent files.

  I wrote a more in-depth explanation of this not long ago, see:

        http://www.mail-archive.com/gnhlug%40zk3.dec.com/msg05276.html

  See also "man hier".

> 3. Is there a common way to run Linux apps (like an exe file on DOS/Win )?

  You simply issue the name of the program.  There is no special file
extension; the system knows a file is executable by looking at the execute
bits of the file permission mode.  If the program is contained in a directory
within your $PATH, then you do not need the full path; otherwise, you will.

  For example, if your $PATH is "/bin:/usr/bin:/usr/X11/bin", then you can run
the "/bin/ls" command simply by giving the command "ls", because "/bin" is in
your $PATH.  However, to run "/sbin/ifconfig", you would need to type
"/sbin/ifconfig", because "/sbin" is *not* in your $PATH.

  One difference between Microsoft OSes and Unix is that under MS OSes, the
current directory, ".", is implicitly included in your $PATH.  Under Unix, this
is not the case.  Say there is a program "runme" in Joe's home directory.  
You first change to that directory with "cd /home/joe".  Then you type "runme"
and hit [ENTER].  You will likely get a "command not found" error, because "."
is probably not in your $PATH.  You need to issue "./runme" instead.

  This is a security feature which prevents you from accidentally running
"trojan horse" programs other users have left lying in wait for you.  It also
lets you specify PATH search order.

> This is a fairly important topic to me.

  And most people, I'd imagine!  :-)

> Maybe it would be possible to dedicate a night or some time at one of the
> gnhlug meetings for this topic.

  We do have "New User Nights" and "Install Fests" and such from time to time,
and questions of any level are always welcome.

  Don't take this the wrong way, but there are some excellent introductions to
Linux available from your favorite bookseller.  "Running Linux (3rd ed.)" by
Matt Welch, et. al., is highly recommended.  Our own Jon "maddog" Hall has
written "Linux for Dummies", which is a good intro for the less technically
inclined.

  Hope this helps!

-- 
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18   Fax: (978)499-7839


**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to