[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ATTN: info/pinfo users



After a long frustrating experience with install-info and the default "/usr/share/info/dir" file, I decided to write a script which bypassed the
"dir" file and read the info entries from the info files themselves and
literally rebuilt the "dir" file from scratch.  This message is to let you
know about this perl script if you are interested.

	The only "disadvantage" to this script is that it does not deal with
sections, it simply builds a single alphabetical list of info entries.
Personally, this is what I want, as I find the different sections to be
confusing, and they make it harder to find what I want.  If this doesn't
bother you, then keep reading.

You can get the script here:  http://pages.xtn.net/~ecogburn/build-info.tar.gz

There is an optional build-info.conf file that you can put in /etc/. For now, this is mainly for if you want to use a max-width value greater than 80 (the
default in the script).  This script will wrap the description in the same
(horrible) way that install-info does if you wish, but this effectively
doubles the listing size (most line lengths will be beyond 80), for no real
benefit as I rarely need to see the (whole) description anyway.  If you set
max-width to 132 or greater there will be no word wrapping on the extreme
right.  This is great if you use a >80 column console or use info/pinfo in an
xterm.  If you use pinfo I reccommend this even if you use an 80 column
display, because pinfo just truncates long lines, meaning you'll probably see
enough of the description to know what it is without needing to see the whole
thing.

This thing will also add entries for info files which do not have an
START-INFO-DIR-ENTRY line in them (like the info for the ed editor).  It will
just use the basename of the file, without a description.

This thing will also look in subdirectories and if it finds a "dir" or
"dir.gz" file in that subdirectory, will read that dir file for entries.  This
means it will catch the XEmacs entry for example as all of XEmacs info is in a
subdirectory.

This thing now finds about 30 more entries than were in my old dir file (which
was broken anyway).

It will not add duplicates.

It will catch the strange entries where the description is missing, or they
put the description on the next(!?!) line.

The options are --version, --help, --debug, --info-dir=xxx --max-width=nnn.
If you want to see what the script will produce without writing to the dir
file, use --debug, as that will switch output to stdout.  You can then
redirect and examine the output in a temporary file.  The script normally
backs up dir to dir.old anyway.  The last two are also supported in the conf
file, so you needn't use them every time.

If you find this doesn't work for some reason let me know.  If you like it,
let me know that too!  :)  Obviously, I can't load every deb with info files
to check them out (I'm on a dialup) so if something breaks it, let me know
what info file does it.  Comments, suggestions welcome.

For those who like to live dangerously:  You could replace install-info with
this instead.  This script will silently accept and ignore all the options
that install-info does.  Since it rebuilds the dir file based on the info
files actually present, its not going to make any of the mistakes install-info
does, although I'm not claiming this script is bug-free.  I've been doing this
for awhile now, and it appears to work as intended, but no promises.  :)



To any Debian developers who may be reading this:

Debian really needs to adopt a new policy for the info files.  What we should
do is simply require all info files to have a full and correct
START-INFO-DIR-ENTRY section, [* name:  (command)command.  description] - all
of it on one line, along with some rules about the length of commands and
names.  This would entirely eliminate the need for install-info as you could
just use a script like this one (with section support) to rebuild the dir file
from the source (by looking in the info files) rather than assume (often
incorrectly) that the current dir file is valid and accurate.




Reply to: