VVDQ : pine??

[Derick Centeno]

Hi Beartooth:
I hope this clears some things up:

On Fri, 2004-12-17 at 12:58, beartooth wrote:
> On Fri, 17 Dec 2004 09:36:13 -0500, Derick Centeno wrote:
> 
> > [aguilarojo at arakus aguilarojo]$ whereis pine
> > pine: /usr/bin/pine /etc/pine.conf /usr/share/man/man1/pine.1.gz
> 
> Maybe something is wrong with my CDs. I had done that -- but got :
>                             =====
> [root at localhost root]# locate pine
> /home/tslg/.pan/gmane/gmane.mail.pine.general
> /home/btth/.pan/Giganews/comp.mail.pine
> /home/btth/.pan/Gmane/gmane.mail.pine.announce
> /home/btth/.pan/Gmane/gmane.mail.pine.general
> /usr/share/gimp/2.0/patterns/pine.pat
> /usr/share/vim/vim62/syntax/pine.vim

The locate command is a more convenient form of the command find.
In this case, locate will find anything with those sequence of letters.
To use find of course one would have to do:
find / -name "pine*" -print > findpine

Meaning: The find command begins it's search at the root directory and
proceeds throughout the entire contents of the harddrive looking for
"pine*".  This means anything with pine... (the dots represents any
combination of numbers or characters) but will not include any sequence
of numbers or characters which precede pine, as in ...pine.  The > tells
the command to print whatever output it has to a file called findpine
which can be opened with any editor.

What follows is my use of locate on my system:
[aguilarojo at arakus aguilarojo]$ locate pine
/etc/pine.conf.fixed
/etc/pine.conf
/usr/bin/pine-spellcheck
/usr/bin/pine
/usr/bin/pinegpg-install
/usr/bin/pinegpg
/usr/bin/pinepgpgpg-install
/usr/bin/evolution-pine-importer
/usr/bin/load-pine-addressbook
/usr/share/doc/pine-4.44
/usr/share/doc/pine-4.44/background.html
/usr/share/doc/pine-4.44/CPYRIGHT
/usr/share/doc/pine-4.44/README
/usr/share/doc/pine-4.44/config-notes.html
/usr/share/doc/pine-4.44/brochure.txt
/usr/share/doc/pine-4.44/bugs.txt
/usr/share/doc/pine-4.44/cmd-line.html
/usr/share/doc/pine-4.44/installation.html
/usr/share/doc/pine-4.44/config.html
/usr/share/doc/pine-4.44/index.html
/usr/share/doc/pine-4.44/introduction.html
/usr/share/doc/pine-4.44/low-level.html
/usr/share/doc/pine-4.44/mailcap.unx
/usr/share/doc/pine-4.44/pine-ports
/usr/share/doc/pine-4.44/porting.html
/usr/share/doc/pine-4.44/tech-notes.txt
/usr/share/man/man1/pine.1.gz
/usr/share/vim/vim61/syntax/pine.vim
/usr/share/gimp/1.2/patterns/pine.pat
/usr/share/zsh/4.0.4/functions/_pine
/usr/share/licq/utilities/pine.utility
/usr/X11R6/lib/X11/xfig/Libraries/Maps/Asia/philippines.fig
[aguilarojo at arakus aguilarojo]$

I'm tempted to get into an analysis of what locate does versus what find
does.  By the way the "*" is a shorthand symbol which Linux/Unix
understands as "anything" as in numbers or characters.  You can discover
the details of how and what manner these commands behave yourself by
executing them on your own system and noticing their output.

Now about whereis:
[root at localhost root]# whereis pine
> pine:

Note that when the whereis command responds in this way that application
you were looking for is not installed.

> [root at localhost root]# rpm -q pine
> package pine is not installed

The query you used of rpm here merely verifies that.


>                         =====
> 
> So I think I still need a download, don't I? 

The problem is probably not the CDs themselves (although that is
possible) regardless of the best quality control available. Rather the
problem may be an old problem which the Red Hat installer Anaconda has
had in the past for a long time and which it may STILL have.  Red Hat
built the Anaconda installer, not Terra Soft, and even though Terra Soft
may get abused, flogged and so on for passing it on, the fact is that NO
Red Hat based distribution gets along without it and so this is a wee
bit of a problem (as my Irish friends would likely say).

My own experience and others may quickly be described as the fact that
Anaconda at the installation phase "forgets" or "unselects" those
programs (and associated packages and dependencies) which a user has
chosen to install.  Of course, I'm guessing -- but it's a good guess.
No common user to work around this kind of problem; an experienced user
with great tenacity of near maniacal concentration could be clicking and
reclicking certain combinations and options of items to install, could
trick Anaconda into behaving properly but most of us are not quite there
at that point yet.  Recourse??  Maybe yell at Red Hat???

Consider that it is more work than it is worth, use yum.  Make sure yum
is itself updated and current.  If in doubt, do:

yum update yum

Below is what happens when I run it:

[root at arakus aguilarojo]# yum update yum
Gathering header information file(s) from server(s)
Server: Yellow Dog Linux 3.0 base
Server: Yellow Dog Linux 3.0 - ppc - freshrpms
Server: Yellow Dog Linux 3.0 - ppc - os
Server: Yellow Dog Linux 3.0 - ppc - updates
Server: Yellow Dog Linux 3.0.1 updates
Finding updated packages
Downloading needed headers
No Packages Available for Update
No actions to take
[root at arakus aguilarojo]#

The statements beginning with No... means that yum is as far as it can
go given that I'm running at YDL 3.0.1

Best Wishes...