Re: Finding installed package files

From: Edward Diener (eldiener_no_spam_here_at_earthlink.net)
Date: 04/04/05 

Date: Mon, 04 Apr 2005 00:45:02 GMT

Moe Trin wrote:
> In article <6qS3e.2870$44.1391@newsread1.news.atl.earthlink.net>,
> Edward Diener wrote:
>
>> A folder that points to whatever executables and documentation the
>> package has, which the end user might need to use or know about, not
>> to all the files installed which would be ridiculous.
>
> First off, the term 'folder' came from the Xerox "Global View"
> desktop,
> which was copied by Apple, then copied by Microsoft. A "folder" in
> that context holds other things (files as well as other folders). What
> you appear to want is a file that lists executables and documentation.

No I want a folder on the desktop, or a directory in the filesystem, which
contains links to the most important information about the installation.
This might be executables and/or documentation and/or sample files and/or
programmer IDE projects and/or whatever. The folder or directory can even be
named the same as the product just installed, think of that !!!

> Probably not extremely useful due to the diversity of things it might
> have to deal with. Besides, I can tell you that 'bc' is installed and
> very useful, but you have to try to figure out WTF is 'bc'.
>
>> The main reason for such a thing is so one knows what functionality
>> has
>> been installed and how it works. I do not see that as so
>> unreasonable.
>
> Used to was, the real paper manual that came with a Linux distribution
> had this. AS A START, you could try 'rpm -qai > some.file.name'. No
> doubt others could finesse the command.

I do understand that rpm has many options that tell me about a package. I
will study these to find out information. Some of the graphical package
managers, like yumex and synaptic, have interesting info but I do not see in
them any post-installation information similar to what the rpm gives one as
you and others have been explaining to me.

>
>> It also makes it easy to execute anything in the product directly
>> from the desktop or a common folder rather than having to use the
>> terminal and type in a command.
>
> I'm not sure you really would like that. As a user, there are 1300
> commands in my PATH - closer to 1650 as root. Obviously, you'd play
> hell trying to pick out the right icon to click on. And this is only
> a work station with about 330 packages installed. Imagine the poor
> sod who installed "everything".

Many packages have a single command, for which a 'man' page is probably
sufficient. But there are some packages, programming languages, compiler
implementations, large multi-purpose programs, which could use what I
suggest. I would bet that out of the 1300 or so commands, 1200+ or so are
the single exe commands you speak about and need no links to them since they
are just executed from a command window. But for the other 100 or so I see
nothing wrong with program folders or directories somewhere where more
information about the key parts of the package reside and are easily
accesible.

As an example I installed the latest Python on Fedora 3. I know Python comes
with a command-line invocation, an Idle interpreter, a help file, and a
small graphical program which searches Python module information from the
Internet. Post installation it would have been nice, as Python does in
Windows, to see a folder somewhere, which had links to these four items so
that I could access them immediately without having to wonder where they are
and what they are called. This is not unreasonable ! I realize that seasoned
Linux users like yourself know means to find out this information in pretty
short order. But for new users coming to Linux, and these are much the same
people of desktop users which Linux may want to appeal to in order to grow
their user base and compete against Microsoft's hegemony, it is not so easy
and often annoying to find out what has been insatalled and may be used. And
no matter what anyone says here, putting all the information about Python,
its language and its libraries, in a 'man' file or many 'man' files reeks
from the dark ages of computer usage and programming. It is much, much
better and much, much easier to use an advanced documentation system for
large scale information that is entailed in a Python distribution. Sure, if
I want to know what a single command with a dozen options does 'man' pages
are sufficient. But they very quickly become insufficient when dealing with
large scale information.

>
>> I am glad that Linux gurus instantaneously know what they have
>> installed and exactly how it works, but for us lesser mortals that
>> is not always the case.
>
> [compton ~]$ whatis whatis
> whatis (1) - search the whatis database for complete
> words [compton ~]$ apropos whatis
> apropos (1) - search the whatis database for strings
> whatis (1) - search the whatis database for complete
> words [compton ~]$
>
> But I'll also show you a little secret.
>
> [compton ~]$ echo $HISTSIZE
> 1000
> [compton ~]$ history | sed 's/^......//' | tr '|' '\n' | sed 's/^
> *//' | cut -d' ' -f1 | sort -u | wc -l
> 78
> [compton ~]$
>
> The first command says how many of the previous commands I've use
> that the shell will remember. The next command (beginning with the
> word 'history'
> and ending with 'wc -l') breaks apart those commands into their
> individual parts, and then counts how many different ones there are.
> So, of the 1300 commands I have access to, I've used just 78 time
> after time.
>
>> I am just suggesting that a good installation of a product tells the
>> user what has been installed and how to use it.
>
> The city just opened a new library about a half mile from my house.
> They
> are using an electronic card catalog - a browser application running
> on some variant of windoze. Intuitive? Yeah, right. How to use it?
> Simple, you just click and guess. Man pages? Sorry dude, this is
> windoze - we don't need no stinkin' man pages. Trying to get the
> thing to search for a book in _THIS_ library, not the other 20 odd
> branches elsewhere is counter-intuitive. So
> I wind up having the staff try to run the damn thing for me. As a
> few of them are really neat chicks, I am less disappointed, but I
> doubt this was
> how they planned to have the system used.

I have no idea what this electronic card browser is but if it has no ability
to search for a book based on common things like author, title, or subject,
then it probably isn't very good to start with. I think you know also this
has nothing to do with Windows, Linux, or anything else. I have used
excellent documentation systems on Windows and I have used horrible
documentations systems on Windows.

>
>> But one has to know what the names of the things installed are in
>> order to call up the 'man' pages for them.
>
> man apropos or 'apropos keyword 1 | grep keyword 2'

OK, that is useful.

>
>> There may be more than one executable installed.
>
> They should each have their own man pages

Not the case when a large package has their own help system. I won't argue
about it but 'man' pages are not appropriate, or easy at all to use, for
largescale documentation.

>
>> There are also a number of products that produce their own
>> documentation
>> in other formats. Despite what some Linux users may believe, that
>> 'man' pages are the epitomy of documentation, I personally believe
>> that for some software a much better documentation system is needed.
>
> Man pages were not meant to teach you how to use everything. The man
> page
> for 'bash' is over 3000 lines - and then there is the
> Bash-Prog-Intro-HOWTO with 1444 more lines, and the
> Bash-Beginners-Guide and abs-guide from the Linux Documentation
> Project (http://tldp.org/guides.html). Then if you want to _buy_
> something, O'Reilly and Associates (www.ora.com) has some absolutely
> outstanding books.

Good. But what is wrong with a documentation system which emulates the way
one reads a programming book, and even improves on it. I see absolutely
nothing wrong with a computer documentation system that has a TOC, Index,
and Search facility. I also see nothing wrong with documentation distributed
using such a format with a nice graphical viewer that makes documentation
easy to find and read.

>
>> For instance Python on Linux has its own HTML help file while on
>> Windows
>> it has a Windows help file which provides even more functionality in
>> the form of a TOC, Index, and Search.
>
> Many people use the 'less' command when reading documentation - your
> man pages almost certainly use less as the pager. Read the man page
> for that command (less) and discover how to use the search function
> that is built in.

Sorry, it is a PITA to me no matter how you tout it. I do understand that
seasoned Linux user are used to it.

>
>> If I see an intersting package which I want to use, and I install it
>> through yumex or synaptic, how do I find out about it post
>> installation ? Well I can search the Internet, or ask questions on
>> NGs, but I would prefer if the installation pointed me to something
>> which told me what I now had
>> in the form of functionality.
>
> I don't recommend just blindly installing something because it looks
> good,
> or the guys at the water cooler said it's the greatest thing since
> sliced bananas. The place to start is before you install.

I do not blindly install. I spent much time trying to remove what I thought
as garbage from my Fedora 3 base system recently. Unfortunately so much of
what I wanted to remove was used by other elements that I wanted to keep.
Still I think Linux's ability to add, remove, and update software is far
superior to Windows, and it is mostly a pleasure to be able to use it when
necessary. It's just what happens after software is installed ( actually
what does not happen ) that was the subject of my OP.

> Applications like rpm
> can be commanded to produce the documentation of a package not only
> after it's installed, but even before. For an installed package, the
> command is 'rpm -qd foo' to list the documentation of package foo,
> 'rpm -qi' to show
> the descriptive data. For an uninstalled package, the command is
> longer,
> but similar: 'rpm -qpd /path/to/foo-1.2.3-45.i386.rpm' And don't
> forget
> that the package may come with a bunch of README, CHANGES, and BUGS
> files that you can find with 'rpm -ql foo'. This is a Red Hat news
> group, so we're talking about rpm - but other package managers have
> similar capability.

As I said, I will learn rpm much better, by reading the 'man' page <g>.

>
>> The attitude, which is unfortunately prevalent throughout the
>> computer software industry but seems ( I hope I am mistaken )
>
> You are not mistaken - it's a way of life in the industry.
>

A way of life that wastes enormous amounts of time and money.

>> especially so among Linux users, of "We don't need no stinkin'
>> documentation" has got to go if Linux is to be successful.
>
> And the response we get from the grunts in the trenches is that you
> can have the product only a few months late, or the documentation -
> but if you want both... No one likes to write documentation.
> Those who know the product are to busy keeping ahead (yeah, right) of
> the bugs - those who
> can write about it don't have the intimate knowledge. What some fun?
> Compare the '--help' output of a command with the man page. Sometimes
> you find a jewel hidden there.

I have heard this all before and I have seen numerous organizations and
companies waste enormous time and resources training and re-training
programmers because nothing was ever written down.

Eddie

Relevant Pages

  • Re: Finding installed package files
    ... for making installation information more easily accessible? ... >> somewhere where more information about the key parts of the package ... >> As an example I installed the latest Python on Fedora 3. ... what one would expect is a form of help documentation much more integrated ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... >, and who is going to supply this documentation. ... > is a package with the common man pages for the thousand odd common commands ... tell me, as an installation option for some large packages, what was ... >>a set of commands and 'man' pages, could produce such a directory to make it ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... >> package, and to have easy access to those files, especially the ones ... >> this as being helpful to Linux users, ... >> Linux could be made easier by having installation programs actually ... be searching for the executable and its command line for invoking the IDE, ...
    (alt.os.linux.redhat)
  • Re: Finding installed package files
    ... you appear to want is a file that lists executables and documentation. ... doubt others could finesse the command. ... how do I find out about it post installation? ... For an installed package, the command is ...
    (alt.os.linux.redhat)
  • Re: Page Layout Problem
    ... %Simply changed to do page numbering by section, ... % Largely reimplemented for use as a LaTeX2e package, ... % This is the command used by \pagenumberingto actually ... (THE DOCUMENTATION IS NOT FIXED, ...
    (comp.text.tex)