Don't put those silly graphic dots in place of HTML list bullets.
First, they waste the users time downloading (each requires another
connection to the server) and second they break the formatting
rules provided with HTML. Its just not good practice and they don't
have any real value add to your pages.
Now that you know some basic guidelines for you images, how do you go about
creating the images? It depends on what kind of images you want to make.
If you want a simple, cartoon-like image you can get a drawing program like
xpaint. This tool is good for drawing circles and boxes and filling them
in, using a window like a canvas to paint on the screen. However, this
tool is limited in what you can do to the image once you've drawn it. One
highly popular tool for a number of platforms that does this
post-processing is Adobe Photoshop. Using a tool like this takes a bit of
practice, but once you've mastered it you can do some rather amazing
things. A Linux alternative to Photoshop is the
Gimp.
The logos on this page were created with the Gimp. So was the background.
3D images are a whole other matter. There are actually more well-known
tools for doing 3D work than there are for doing image manipulation (ie
tools like the Gimp). Probably the best known of these is POV-Ray. This
tool reads in a text file that uses a "scene description language" to describe
how objects in the scene should be positioned and textured. The drawback
to these tools is that they lack a point-and-click interface.
There are separate tools available,
known as modellers, that allow the creation of the scene files without
actually rendering the image. In order to create 3D image you need to
either learn the scene description language or learn who to use a modeller
that will create it for you.
I know this is fairly basic and undetailed, but this is just my first
column. Over time I'll try to cover both beginner and more advanced issues.
Future Directions
Next month: How do you create the textures that get applied to 3D images?
Beyond that, I'm considering talking about how to use Type 1 fonts in your
images: how to install them, how you can manipulate them with the Gimp to
make interesting logos, etc. I'd also like to provide some tips for using
POV-Ray and BMRT (although I have a lot to learn about the latter). And I
might try to cover a little on how to do animations. Things are pretty
open right now.
Let me know what you'd like to hear about!
"Linux Gazette" Penguin courtesy of
Larry Ewing.
Copyright © 1996, M. J. Hammel
Published in Issue 11 of the Linux Gazette
![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
"Linux Gazette...making Linux just a little less scary!
"
A "Kill-Ring" Menu For Xemacs
Copyright © 1996
Published in Issue 11 of the Linux Gazette
Lately I've been enjoying exploring the myriad capabilities of GNU Emacs'
offspring and competitor, Xemacs. Aside from the burden of downloading the
voluminous source, Xemacs offers quite a few features which Gnu Emacs
lacks. Luckily for those considering a transition, the basic keystrokes and
commands are nearly identical.
One feature of Gnu Emacs which I began to miss after a while was the handy
pull-down menu which displays the first few words of each cut or copied
selection made in the current session, i.e. the "kill-ring". The prospect of
figuring out how the lisp files work which determine the menu-bar's structure
wasn't too appealing. I know a little lisp, but not enough to add a new menu
entry.
Some weeks later, while idly browsing through some emacs newsgroup
headers, I came across this posting, which I'll quote here in full:
In article <9604170740.AA26236@portia.uk.abs> imac@portia.rd.abs.alcatel.co.uk
(Ian MacKinnon) writes:
> When I used emacs (before I saw the light), I made use of a function
> mouse-menu-choose-yank which offered you the choice to yank from the recent
> history of selections via a popup menu, but I can't get it to work in
> XEmacs because x-popup-menu doesn't exist, and the parameters to
> popup-menu are different. Has anyone got an alternative. I enclose the
> ...
I have hacked the Emacs codes of mouse-menu-choose-yank to put in
Xemacs as follows:
(defvar yank-menu-length 40
"*Maximum length of an item in the menu for select-and-yank.")
(defun select-and-yank-filter (menu)
(let* ((count 0))
(append menu
(mapcar
#'(lambda (str)
(if (> (length str) yank-menu-length)
(setq str (substring str 0 yank-menu-length)))
(prog1
(vector
str
(list
'progn
'(push-mark (point))
(list 'insert (list 'current-kill count t)))
t)
(setq count (1+ count))))
kill-ring))))
For this to work, you have to put on your menu bar the following submenu
(use add-submenu for that for example):
("Select and Yank"
:included kill-ring
:filter select-and-yank-filter)
Hope this help
-----------------------------------------------------------------------
PHAM Dinh Tuan | e-mail: Dinh-Tuan.Pham@imag.fr
Laboratoire de Modelisation et Calcul | Tel: +33 76 51 44 23
BP 53, 38041 Grenoble cedex (France) | Fax: +33 76 63 12 63
-----------------------------------------------------------------------
It took a little experimenting to get this to work. The first section
of lisp code, ending with "kill-ring))))", can be copied unaltered into
the xemacs section of your ~/.emacs file. If you're using Xemacs 19.14
(the current version), it goes into your ~/.xemacs-options file.
The second, shorter lisp snippet needs one small addition:
(add-submenu nil '("Kill-Ring"
:included kill-ring
:filter select-and-yank-filter))
As well as adding the proper syntax for add-submenu, I shortened
the menu-title, but it could be called anything you like.
When I first restarted Xemacs after placing this code into the init file
the new submenu was nowhere to be seen. I surmised that I'd made some error,
and put off further experimentation for another time. A few minutes later I
was busily editing some file. I happened to glance up at the menu-bar and
found a brand-new kill-ring submenu. Surprisingly the new menu only appears
after a selection has been cut or copied.
I was happy, and thought that by relating my experience I could encourage
other Xemacs users (especially the ones who know as little lisp as I do!) to
try this neat hack. Thanks to Dinh Tuan Pham, if he or she should happen to
see this.
"Linux Gazette...making Linux just a little less scary!
"
Linus to Move to U.S. in 1997
Copyright © 1996
Published in Issue 11 of the Linux Gazette
Linus Torvalds is currently in the process of finishing up his Master's
degree at the University of Helsinki. After degree completion, he plans
to move to Santa Clara, California, where he will begin working for
Transmeta in March, 1997. Since Transmeta does not do Linux,
this is a Linux-neutral position; however, his
contract includes a provision for time to continue work on Linux.
After careful consideration of what he wanted in the future for himself and
his family, Linus decided to pursue a position in the business world.
A friend of his, who works for Transmeta and who has been a
long-time Linux contributor, talked to his management and found
a position for Linus that would both utilize his talents and interest him.
Linus feels that the match between Transmeta and his future goals is a good one.
Transmeta is a relatively small company. While Linus' main job will not
be working on Linux, Transmeta recognizes the good that Linux is doing, and
will allow Linus time and freedom to continue with the Linux project.
Here at Linux Journal we see this as a chance to let Linus trade in
some of that virtual beer we owe him for the real stuff.
While not exactly around the corner, being on the same coast and within
about two hours by airplane makes the trade a lot easier.
While some have expressed fear that Linus' choice to apparently have a
life could adversely affect Linux development, I think this is
not the case.
Those of us who have had the opportunity to sit down and talk with Linus
know that Linus already has a life.
While he spends a lot of time working on Linux, he does have other interests.
The goal in attending the University of Helsinki was to get a degree, not
to build the operating system we are all now involved in.
I think his decision to go to a Linux-neutral company, even though
he had job offers from companies working with Linux, will be an advantage
to the Linux industry as a whole. Also,
being in the U.S. will make it easier for Linus to participate in shows
and other events here, while still maintaining a personal life.
Besides, it is going to be nice to be able to say that the person who
created our operating system of choice has a job.
-- Phil Hughes
Publisher of Linux Journal
"Linux Gazette...making Linux just a little less scary!
"
Running Sun's Hotjava Browser on a Linux System
Copyright (c) 1996
Published in Issue 11 of the Linux Gazette
Introduction
Recently I stopped by the
Java-Linux
web-page to see what was new and found an intriguing new link. This link
took me to a page which contains a script allowing Sun Microsystem's HotJava
web-browser to be run on a Linux machine. I was skeptical, as the Java-based
browser supposedly is only available in versions for Win 95/NT and Sparc
Solaris systems. The comments in the script stated that the Sparc version
should be downloaded and installed, after which the new script should be
edited to reflect the location of the Java Developers Kit on the machine.
The comments were rather terse; what I wanted to know was whether it worked
well enough to even bother with.
Download and Installation
You've probably guessed that my curiosity got the better of me; feeling
faintly foolish I FTP'ed the three-and-one-half megabytes of Sparc binaries
from the Javasoft site and installed
them. After substituting the new start-up shell script for the supplied
script I was ready to try it out. The first try it died, complaining that it
couldn't find mkdir in /usr/bin. I re-edited the shell script and
corrected that path. This time it worked, and I have to say I was impressed.
So What's It Like?
HotJava is a graphically well-designed browser. The graphics in the
various help-pages, the buttons, and the general design are all professionally
executed, and pleasing to the eye. Here is a screen-shot of one of the
included monitor applets:
The browser takes about as long to start up as Netscape does. It's
informative to start it from an xterm window, as verbose messages scroll by
throughout the session indicating what threads and applets are active.
You'll also be able to see its dying words, as (at least on my machine) it
will only run for about one-half an hour before crashing. While it runs it
seems to do well, though. I aimed it at http://www.gamelan.com and tried a
variety of java applets. They seemed to take longer to load than with
Netscape, but once loaded worked well. Frames, once a Netscape exclusive,
are supported. There is also a menu option allowing hotlists from other
browsers to be imported.
In its current "pre-beta" state HotJava uses an awful lot of
memory. Top reported usage of fourteen to fifteen megabytes! No wonder
I could only start it when the machine was lightly loaded. The current version
of the Linux java compiler is a memory hog as well, so perhaps this is a trait
of java, being an interpreted language as it is.
HotJava includes two interesting monitor applets. One shows the current
memory usage in bar-graph form, with a button which will clear past images and
pages from memory, rather like Netscape's "clear memory cache" function. The
other shows a list of all of the active threads, with often as many as twenty
to thirty active at once.
I did notice that if used locally; i.e. for viewing HTML files on the local
hard disk rather than on the net, it wouldn't crash. GIF and JPEG images
referred to from a page (rather than inline on the page) are viewed in the
same window with an internal viewer. This is in contrast to some browsers
which call an external program for this purpose.
I should state here that I don't have the Java Developer's Kit version 1.02
patchlevel 2 installed; my installation is the plain 1.02. Patchlevel 2 is
recommended on the Java-Linux page. Perhaps some of the problems I had with
HotJava can be attributed to my slightly out-of-date JDK.
Conclusion
Even with all of the faults related above my overall impression was
positive. Remember, this is a pre-beta release. HotJava is a major
evolutionary step up from the web-page applets which are the most common
uses of java these days. What other large application written in java is
available? It is a tribute to the inherent cross-platform nature of the
java language that a release intended for Sparc Solaris machines will run at
all on my humble 486 Linux box. Thanks go to whomever modified the
hotjava script and made it available on the Java-Linux site!
Larry
Ayers<layers@vax2.rain.gen.mo.us>
Last modified: Sat Oct 26 17:29:28 CDT 1996
"Linux Gazette...making Linux just a little less scary!
"
The TkGoodstuff Package
Copyright © 1996
Published in Issue 11 of the Linux Gazette
Introduction
For the past couple of years Mark Crimmins at the University of Michigan has
been developing and refining an extremely configurable desktop button-bar;
since it's written in Tcl-Tk and superficially resembles the Fvwm Goodstuff
module, it is known as TkGoodstuff. The utility has passed through several
beta versions in the last year. Recently Mark made available a release version
4.1, so I thought this would be an auspicious time to review it.
Features
TkGoodstuff is really a package of "clients", which are modular utilities,
organized and displayed by the master program. Some of the client utilities
were written by Mark Crimmins, while others were contributed by
users. They include:
- Window-list: displays running programs a la Win95
- Pager: Compact pager, like fvwm's
- Biff: Mail notifier
- Net: Net status indicator, can also launch scripts
- Dialer: Configurable ppp/slip script-generator and launcher
- Jots: Notepad utility
- Watchdog: Monitors any logfile for changes
- Clock: Any sort you like
- Load: Like a miniature xload
- Many others! Consult the web-site for descriptions
TkGoodstuff includes a tabbed-notebook style configuration utility, which
allows a multitude of settings to be made for all of the clients. Colors,
icons, fonts, and nesting of clients can all be determined here. Configuring
a utility like this one can be extremely time-consuming. I like to rough out
the configuration in one pass, live with it for a while, then make incremental
changes from time to time as they occur to me. After making any change in the
configuration notebook a window pops up giving you the opportunity to restart
Tkgoodstuff (hereafter referred to as Tkg).
Tkg is designed to cooperate with and interact with Fvwm; it can be loaded
as an Fvwm module either at start-up or from the mouse-menu. If run as a
module the button-bar will "stay on top" and inhabit all pager windows. There
is also an option which allows Tkg to span any of the four screen edges.
On my system PPP dial-up sessions are initiated by means of a short shell
script called ppdi. I recently discovered that the Tkg Net
client can launch this script when its panel is mouse-clicked, and terminate
the session the same way by launching the ppp-off script. This is just
marginally easier than finding an rxvt window and typing the commands in, but
much easier to explain to my wife and kids! The Net button also shows
total time online when a connection is open.
Modules which are used less often can be invoked from a submenu viewed by
clicking the Utilities button.
My favorite configuration uses a small subset of the available modules,
with the window-list and pager combination occupying the lower half of the
bar.
Tkg comes with ample documentation in the form of linked HTML files. A
tutorial is even included which provides help for creating your own modules.
Availability and Installation
TkGoodstuff is available from the major Linux archive FTP sites, but its home site will have the
most recent version. The compilation and installation process is
well-documented within the package; the current version (4.1) does require
Tcl-7.5 and Tk-4.1.
Larry
Ayers<layers@vax2.rain.gen.mo.us>
Last modified: Tue Oct 22 09:25:55 CDT 1996
"Linux Gazette...making Linux just a little less scary!
"
X-Files
Copyright © 1996
Published in Issue 11 of the Linux Gazette
From two Finnish college students, Juha Forsten and Mikko Kiviniemi, comes
a new variation on the theme of translating basic Unix commands into a
graphical form with Tcl/Tk. X-Files superficially resembles FileRunner
(reviewed in LG #9) due to a shared ancestry: those legendary Amiga
file managers which seem to inspire such loyalty and nostalgia. This new one
has quite a list of features, all of which are configurable to an extreme.
Features, Some Unique
X-Files is one of those apps which you could spend hours customizing. The
X-Files window at first glance seems cluttered and busy, with row after row of
multicolored function buttons. I believe the authors set up the default
configuration this way so a new user could see all of the possibilities at a
glance. Click here to take a look: Initial View
Exploring further I found that a pull-down menu allows the default
button-arrangement to be exchanged for any of three alternate choices.
Alternately, any individual row can be disabled. As a further refinement there
is an entry under the "config" menu item which allows the appearance and
behavior of any button to be edited. A small edit-window pops up after you
click a mouse button on whichever button you'd like to change. The color,
button text, and command you'd like the button to run can be entered in and
saved. Entire groups of buttons, each optimized for a certain project or type
of work, could be created. They would then be available from the menubar.
Another built-in mini-editor is also available from the menubar. This one
allows specific behavior to be assigned to various file extensions. If you'd
prefer the Gimp rather than XV to be the default image viewer for jpg files
this'll let you do it. A separate program or action can be assigned to each
of the left and middle mouse-buttons.
The references to left and middle in the above statement seem
to refer to a three-button mouse. X-Files was written with this sort of mouse
in mind and can be a little awkward to use with a two-button mouse, like mine.
Even if you have emulate three-button mouse set in your XF86Config
file, double-clicking both mouse buttons at once takes a while to get used
to.
I was pleased to see complete keyboard-control support in this file manager.
The arrow keys and page-up and page-down keys work in whichever directory pane
the mouse cursor is in. The focus follows the mouse without clicking, even to
list-boxes and entry-fields. Lack of this feature is a shortcoming in the
other two Tk file managers I've written about, Tkdesk and FileRunner.
The mv command in Linux (and other Unix variants) has a peculiarity:
it refuses to move a file from one partition to another. Most file managers
I've used deal with this by means of a behind-the-scenes subterfuge. While
the user thinks the manager is moving the file, it's actually copying the
file, then quickly deleting it from the original location. The overall effect
is the same. The Move button in X-Files hasn't learned this trick yet,
but I imagine after a few more version releases it will. This behavior has
an effect upon file deletions which puzzled me for a while. X-Files would
occasionally refuse to delete files for no apparent reason. What was
happening was a result of X-Files' use of an undelete/trashcan directory. This
directory (~/.xfiles/xfiles_dumpster) is created during installation, and the
default behavior is to move all deleted files to this directory. This would
be fine if all your files were on the same partition; if they're not X-files
will balk. Luckily this feature is easily disabled; I prefer irrevocable
deletion anyway.
A "virtual file system", similar to but not quite as refined as the Midnight
Commander's, allows the contents of zipped and tarred and gzipped files to be
browsed. In this beta *.tgz files are supported, but not
*.tar.gz files.
Licensing and Availability
X-Files has many other features; why not check out the X-Files Home page and find out
more? The source can be downloaded from the page as well. As of this writing
(early October) it hasn't shown up on the archive sites.
This program isn't completely free. The terms are similar to those of John
Bradley's XV image viewer: it's free to individuals, but for business and any
other multiple-user use it costs twenty dollars to register. The authors also
hint that feature requests from those who have paid will be more likely to be
acted upon. An individual wishing to be a "supported user" only has to pay ten
dollars.
Conclusion
I consider X-Files to be a direct competitor in features and utility to
both FileRunner and the Midnight Commander. Tkdesk and Moxfm are in a
different league; they're much more than file managers, though many of the
functions are comparable. The Midnight Commander has the useful trait of
running in a console session as well as in an rxvt or xterm window. Because of
this, Midnight Commander is among the first apps I resurrect after
repartitioning and reinstalling Linux. I'm just happy that we now have
choices in applications for Linux; it wasn't that long ago that Linux users
were glad to have just one of each type of app or utility.
Larry
Ayers<layers@vax2.rain.gen.mo.us>
Last modified: Tue Oct 22 09:24:14 CDT 1996
"Linux Gazette...making Linux just a little less scary!
"
Subject: TAPR SS Position Statement
Date: Thu, 26 Sep 1996 12:18:44 -0700 (PDT)
From: Steve Stroh
To: Phil Hughes WB6SWR
I suspect that the "Intranet" described below will be built on Linux-based IP
routers, possibly a simple implementation that can be booted from floppy
or Flash Card.
It's going to be very, very interesting.
Steve N8GNJ, strohs@halcyon.com
Amateur Radio TCP/IP
n8gnj@sw.n8gnj.ampr.org
| Amateur Spread Spectrum is the wave of the present!
TAPR's Statement on Spread Spectrum Technology Development
TAPR was founded in 1982 as a membership supported non-profit amateur radio
research and development organization with specific interests in the areas
of packet and digital communications. In the tradition of TAPR, the Board
of Directors at their Fall 1995 meeting voted that the organization would
begin to actively pursue the research and development of amateur radio
spread spectrum digital communications. At the Spring 1996 board of
directors meeting, the following statement of purpose was passed:
"TAPR believes that the technical facts support our conviction that
conventional and spread spectrum systems can coexist without detriment to
conventional systems on all frequencies from MF to EHF. To this end, TAPR
will begin to research spread spectrum systems that will develop technology
for future deployment."
As stated above, the TAPR board feels strongly about TAPR's focus on spread
spectrum technology and especially how it relates to the potential
coexistence on frequencies that will have increased number of users
occupying them. The amateur radio bands, like other spectrum will become
more heavily utilized in the future. It is in the interest of amateur radio
to develop systems that are interference-resistant while not interfering
with other primary or secondary users on those frequencies.
TAPR understands the concerns many have with the new technology, and
believes that efforts in both education and research is necessary in order
to allay the fears about interference and to demonstrate the benefits of the
technology.
TAPR believes that todays' communications technology is moving toward all
digital transmitters and receivers. These advances in technology, combined
with the swift evolution of cell based transmission and switching protocols,
are opening up a new set of possibilities for unique new services utilizing
intelligent networks. These will contain smart transmitters, receivers, and
switches. Today's Internet is perhaps the best example of a self-regulating
structure that embodies these new technological approaches to communications
in the networking domain. However, to date, many of these innovations have
not moved into the wireless networking arena. TAPR will work on moving
these innovations into the amateur radio community.
TAPR feels that the VHF/UHF/SHF radio networks of the future will involve a
mixture of links and switches of different ownership, which terminate at the
end-user via relatively short-distance links. What will then be required is
a built-in, distributed, self-governing set of protocols to cause the
network's behavior to make more efficient use of a limited, common shared
resource, the radio spectrum. Creating such a self-regulating structure for
the optimal sharing of spectrum will require much effort.
One of the major problems which stands in the way of these new approaches
today is the current FCC regulatory environment and the manner in which
spectrum is managed and allocated under its rules.
Historically, the current regulatory approach to radio has been based upon
the technology that was in use at the time that the Communications Act of
1934 was framed, basically what we would call today, 'dumb' transmitters
speaking to 'dumb' receivers. The technology of that time required reserved
bandwidths to be set aside for each licensed service so that spectrum would
be available when needed. Given this regulatory approach, many new
applications cannot be accommodated since there is no available unallocated
spectrum to 'park' new services. However, given the new set of tools
available to the entrepreneur with the advent of digital technology, what
once were 'dumb' transmitters and receivers can now be smart devices which
are capable of exercising greater judgment in the effective use and sharing
of spectrum. The more flexible the tools that we incorporate in these
devices, the greater the number of uses that can be accommodated in a fixed,
shared spectrum.
Therefore, TAPR will focus its spread spectrum effort in the following
areas:
- TAPR will work to promote rules and technologies to make the most efficient
use of the spectrum through power control, forward error correction, and
other means to minimize interference among spread spectrum users and
existing communications systems.
- TAPR will work on issues and efforts with other national organizations to
change the regulatory environment and rules in order to promote the
experimentation, development, and later deployment of spread spectrum
technology.
- TAPR will work to develop information on the topic to help educate members
and the amateur community as a whole about spread spectrum technology, and
to disseminate this information via printed publications, the World Wide
Web, presentations at conferences and meetings, and other means.
- TAPR will work to foster experimentation, development, and design of spread
spectrum systems, and to facilitate the exchange of information between the
researchers and other interested parties.
- TAPR will work to develop a national intra-network to foster the deployment
of future high-speed spread spectrum systems into regional and local
communities, including the development of suitable protocols and guidelines
for deployment of these systems.
- TAPR will work with commercial companies who manufacture spread spectrum
devices which operate in spectrum shared by the amateur radio service (ARS),
in order to make them more aware of the nature of ARS operations on those
bands with the goal to work towards the deployment of devices which will
minimize interference between all spectrum sharing partners.
- TAPR will work with commercial companies who manufacture spread spectrum
devices in order to identify equipments that can be either used or modified
for use for Part 97 operation.
Adopted by the TAPR Board on September 20th, 1996
at Seatac, Washington Board Meeting.
Spread Spectrum Statement Committee:
Greg Jones, WD5IVD
Dewayne Hendricks, WA8DZP
Barry McLarnon, VE3JF
Steve Bible, N7HPR
"Linux Gazette...making Linux just a little less scary!
"
My Experience Installing TCL/TK
from 7.4 to 7.5
on Red Hat Linux 2.1, kernel release 1.2.13
Copyright © 1996
Published in Issue 11 of the Linux Gazette
In which I chronicle my experiences attempting to upgrade my version of
TCL/TK to match the web-based help files I had already obtained.
For the short version, click here
On with the story!
Naturally, the first thing I looked for was the RPM. Found it,
couldn't get it because Red Hat FTP was _slow_ during daytime. So I
went to sun.
There I found tcl7.5 (I'm cautious - don't want to use beta stuff when
I can avoid it. That is until I'm independently wealthy with time on
my hands!). Look for:
ftp://ftp.sunlabs.com/pub/tcl/tcl7.5p1.tar.gz
That's the file I got. Download it. While you're there, get:
tk4.1p1.tar.gz
I created a directory off my home:
~/tcl
and put both files in there. From there I unzipped them to get two subdirectories:
~/tcl/tcl7.5
~/tcl/tk4.1
Both of these contain a README file - I read it (but only closely
enough to see that there was a README in the 'unix' subdirectory that
would give me info on how to compile.
So, I changed to the unix subdirectory:
~/tcl/tcl7.5/unix
And read the README file. It said run "configure" (which just checked out
my machine), and then run "make" (which does about what you'd expect),
then run "make install". All of these appeared to work, but when I ran
'wish', I still had the old versions. Hmmmm.
Put it on the back burner for a while - I've other work to do. When I
got home, I looked up the files again (and found the RPM this time),
and downloaded them (at 28.8, instead of T-1 :(
Next morning...
First thing is try the RPM. No luck - it said the .rpm was a 'version
3' RPM, and that I needed to upgrade my version of RPM. Okay - glad
I've got two machines at home (Thank you, Mom, for giving me your old
'486!), I started up the Windows box (I'm looking forward to getting
WABI so my wife can play FreeCell in a _real_ OS :) and started surfing
again...
Does anybody know why the rpm says that rpm2.2.rpm is a version 3 rpm
and I need to upgrade?
While I was finding this out, I was exploring other avenues. I got the
files from sun installed on my machine at home. But they wouldn't
compile (something about missing include files - this didn't surprise
me, I've stripped that machine back in the name of hard drive space).
So, being the explorer I am, I got out the 'sun archives' CD from my
Red Hat install set. Did a 'find' for "*.tcl" and was happy to see
there was a tcl7.5p1.tar.gz file. Good. Ungzipped the thing and 'tar
tvf'ed it to see what was in it. Hmmm. "./usr/..." Looks like I
should just untar it from the root directory. I'm not so cautious when
I'm frustrated.
This option took a _lot_ of drive space. I wish I could undo it. It
didn't really work (and it complained about not being able to form
links. I tried to do the links myself, but it still failed).
Nap time...
That was relaxing. I realized I'd been able to compile at the office,
where it was all the same setup, so I could play with "make install" at
home and see what I could do.
While I was connected to work, I had the idea to try "wish" from the
compiled directory at work. IT WORKED! Headway at last! (Did I also
mention that I'm sometimes a bit slow?) But I've got this really ugly
hierarchy of files to my compiled copy of 'wish', and I don't know what
it's going to look for. Copy to my home machine.
Here's the part where things go quickly.
On the home machine, I set up the directory structure I had at work and
untarred the files. Now I've got a working copy of wish and tclsh.
I created a 'bin' directory off my home directory and copied 'wish' and
'tclsh' into that directory. I also copied the two 'lib' files
"libtcl7.5.a" and "libtk4.1.a" into the bin directory. I don't know
where they really go, but this place makes good sense.
So I run 'wish' from there. Error message - unable to load 'libtcl'
from a list of directories. I'm not sure what they all were, but one
was '~/library'. Since it worked from ~/tcl/tk4.1/unix, I just copied
the '~/tcl/tk4.1/library' directory to '~/library', and then copied
'~/tcl/tcl7.5/library' to '~/library'.
Now wish ran with the right version. Delete the ~/tcl structure
(backup just in case!) and it worked. Good enough. I played with my
working install of tcl/tk quite happily the rest of the day.
But during the night...
"I've got to set it up to work better!"
So, I get to work and get 'wish' to give me an error message - it
complained that the 'init.tcl' was not found in
'/usr/local/lib/tcl7.5'.
Okay. I went to '~/tcl/tcl7.5/library' and copied the files I found
there to '/usr/local/lib/tcl7.5' (a directory which I had to create, by
the way).
Run 'wish' again, and this time it complains about 'tk.tcl' not being
found in '/usr/local/lib/tk4.1'. I'd expected something like that.
So, create '/usr/local/lib/tk4.1' and 'cp ~/tcl/tk4.1/library/*
/usr/local/lib/tk4.1'. And it worked!
Then 'cp ~/tcl/tcl7.5/unix/tclsh /usr/bin/tclsh7.5' and 'cp
~/tcl/tl4.1/unix/wish /usr/bin/wish4.1'. Go to ~ and run 'wish4.1'.
It worked again! Good, create the link 'ln -sf /usr/bin/wish4.1
/usr/bin/wish' and 'ln -sf /usr/bin/tclsh7.5 /usr/bin/tclsh'
Try it again; 'wish' - and success!
Things I found out:
- In Red Hat 2.1, the tcl/tk libraries are in /usr/lib, but the upgrade
looks for stuff in /usr/local/lib. Can anybody explain this
relationship to me?
- The script '~/tcl/tcl7.5/unix/configure' has a pair of options:
--prefix and --exec-prefix. They have something to do with where
tcl/tk expect things to be. Anybody know exactly what?
Short Summary:
Get ftp://ftp.sunlabs.com/pub/tcl/tcl7.5p1.tar.gz and tk4.1p1.tar.gz
'gunzip' them and 'tar xvf' them
'cd ./tcl7.5/unix'
'configure'
'make'
'make install'
'cd ../..'
'cd ./tk4.1/unix'
'configure'
'make'
'make install'
cd ../..
'cp ./tk4.1/unix/wish /usr/bin/wish4.1'
'cp ./tcl7.5/unix/tclsh /usr/bin/tclsh7.5'
'ln -sf /usr/bin/wish4.1 /usr/bin/wish'
'ln -sf /usr/bin/tclsh7.5 /usr/bin/tclsh'
'mkdir /usr/local/lib/tcl7.5'
'mkdir /usr/local/lib/tk4.1'
'cp ./tcl7.5/library/* /usr/local/lib/tcl7.5'
'cp ./tk4.1/library/* /usr/local/lib/tk4.1'
At this point, I'm pretty sure 'wish' will work. But no guarantees.
And there will also be a bunch of files left over from any previous
installation of TCL/TK. Maybe someday I'll clean them up. Probably
not till I get the new Red Hat 4, tho...(I've got to remember to tar &
gzip my 'home' tree before that install!)
Earl
"Linux Gazette...making Linux just a little less scary!
"
Welcome to The Linux Weekend Mechanic!
Published in the November Edition of the Linux Gazette (#11)
Copyright (c) 1996 John M. Fisk <fiskjm@ctrvax.vanderbilt.edu>
The Linux Gazette is Copyright(c) 1996 Specialized Systems Consultants Inc.
You've made it to the weekend and things have finally slowed down.
You crawl outa bed, bag the shave 'n shower 'cause it's Saturday, grab
that much needed cup of caffeine (your favorite alkaloid), and shuffle
down the hall to the den. It's time to fire up the Linux box, break out
the trusty 'ol Snap-On's, pop the hood, jack 'er up, and do a bit of
overhauling!
Time to become the Linux Weekend Mechanic!
Table of Contents
Glad you asked... :-)
After a very busy year creating, writing, editing, proofing, and producing the
first eight issues of the Linux Gazette I'm happy to say that it's been
turned over to the kind folks at the Linux
Journal who will be continuing its production. My special thanks to
Phil Hughes, the producer of the Linux Journal who first broached the
subject of taking over the Gazette when the time commitment was getting out of
hand, AND to Marjorie Richardson, the new editor of the Gazette whose
wit and wisdom should ensure that the LG will continue to flourish.
And now that someone else is doing the day to day management of the Gazette
I'm back to reading, writing, and tinkering -- and this is what the Weekend
Mechanic is all about.
I'd like to try to put together a monthly column for the Gazette that deals
with customizing and running Linux on a personal, stand-alone (i.e.,
not directly networked) PC. The scope of topics may include things such as:
- Shell Programming
- Shell Customizations
- Program Reviews
- Useful Utilities
- Simple Tcl/Tk Scripting
- Dial-Up PPP Setup and Tips
- And so forth...
Basically, it covers the topics that I've found interesting using Linux on my
PC at home -- I've got a shiny new Cyrix P-166+ machine as of August of this
year and have 'Net access via a dial-up PPP connection. So, since I'm writing
from my own experiences, you can anticipate the types of topics I'd likely be
covering. I should add one important proviso: Keep in mind that many of
the suggestions and ideas are NOT useful or recommended in a networked or
multi-user setting in which security is an issue!!
Let me say this another way:
Caveat Emptor!
Because I have a stand alone box and a wife who absolutely hates using
computers I'm the only one that has physical access to my machine. For this
reason, security is not something that I've had to deal with. However, at
MTSU, where I'm currently in school, we use
both HP-UX machines and a number of P-133 machines running Red Hat 3.0.3 Linux
with the 2.0 kernel upgrade. Security on these Linux boxes has been a VERY
REAL issue of late -- if you're running Linux and someone else has potential
access to your machine you'd be well advised to think twice before trying
everything I might suggest. That's not to put a damper on anyone's
enthusiasm, but having one's system hacked is a serious bummer.
And now that that's been said, I really do hope that the information here will
be useful or helpful. The more I use Linux the more I'm amazed at its depth
and breadth and the range of tools and programs that are available. It is
seriously fun!
For this reason, I've decided to use the "Weekend Mechanic" motif.
Thing is, if you're running Linux you've undoubtedly discovered that it takes
more time to set up, configure, and fine-tune than most shrink-wrapped OS's.
It's a "high needs" OS. Now, you could use one of those
fancy-shmancy off-the-shelf Brand X OS's, but the question you have to ask
yourself is...
Do you really want to be see hanging around an OS that looks like it comes
with training wheels...?!!
I don't think so... ! ;-)
So, if you're one of those "I'd rather have a '68 Pontiac with a big
block V8, Rochester QuadraJet, Dualies, and a box of Snap-On's than anything
else" kind of folks...
Relax, you're in the right place. Welcome aboard :-)
For anyone who's been regularly reading the comp.os.linux.* hierarchy you'll
realize that there's been a LOT happening recently within the Linux community.
Here's just a smattering of some things that you might find interesting as
well as other odds-n-ends.
Oh, and BTW...
Happy Halloween!
And now, back to the news...
Caldera to
release source code for DR DOS, CP/M, Novell DOS, and PalmDOS
Yup, you read that right!
Caldera has announced that it is
in the process of a planned release of source code for DR DOS, CP/M, Novell DOS,
and PalmDOS AND the beginning of a project which they are calling
OpenDOS. The announcement stated a tentative date of the first quarter of
1997 for this to occur. Drop by and have a look. I think you'll find it
interesting.
If you've got the hard drive space and want to do a bit of hacking away at
something new, here's an interesting opportunity.
Did you know that
there's a "FreeDOS" Project underway...?
Yup, there's a group working on a freely available version of a DOS-like OS.
You can find out more on what they're doing, how to get a copy of the current
version, and how to contribute to this effort by checking out the
FreeDOS
home page at sunsite.unc.edu/pub/micro/pc-stuff/freedos/freedos.html.
And speaking of new toys...
StarOffice and
Adobe beta software for Linux!
StarOffice, a German software developer, has recently announced a freely
available beta version of its StarOffice suite of productivity
applications for the Linux OS. This is a seriously cool application suite
that has a LOT of high end features. One caveat: you'll need a copy of
the Motif libraries in order to run these applications. If you don't have
motif, then you might want to try some gentle arm-twisting to see whether the
folks at StarOffice would release a statically-linked version.
For those of you with Motif, you can get the installation "disk
sets" at any sunsite mirror such as:
GA Tech's
FTP Linux Archive
in their /pub/linux/apps/staroffice/ directory. Also, Adobe has just
announced a beta version of their Adobe Acrobat 3.0 reader for
the Linux OS. You can find out the particulars of how to obtain a copy
at:
ADOBE's WWW site
in their /acrobat/readstep.html page. I just got a copy of this and the
installation was a breeze. At least on my system, load time was about
what all motif-based apps tend to be (read: "somewhat slow")
but performance thereafter was really quite good.
If you're interested in having a peek at a screen shot with one of the
distributed pages, here's a look at it:
ADOBE Acrobat 3.0 screen dump (~40K) 810x630
Keep in mind that the official stance is that it is only supported under the
Yggdrasil Fall '95 Linux distribution. However, under my 'ol
Slackware '96 it runs just fine... Also, you'll notice the subtle
subliminal message in the titlebar... :-)
And speaking of distributions...
Slackware '96 is
out and Red Hat Rembrandt is on its way!
Now that the Linux kernel 2.0 is out and, for most folks, ELF is in, you'll
find a number of much-awaited distributions with the 2.0 kernel and necessary
development utilities. If you've been waiting to upgrade then now's the time!
There is a growing number of very good Linux distributions available, many of
which now incorporate the recent kernel and development set upgrades. I've
just installed Slackware '96 (AKA Slackware 3.1) which I received
from the folks at
Walnut Creek
who are the official distributors of Slackware Linux. Since it was also my
birthday recently my wife just got me a copy of the August, 1996 Linux
Developer's Resource 6-CD Set from
InfoMagic
Both of these are VERY nice sets that run in the $25 - $40 range and include a
boatload of program sources from the usual linux FTP archive sites
(sunsite.unc.edu, tsx-11.mit.edu, prep.ai.mit.edu, and so forth). Those of
you who are on the monthly Mo' Linux mailing from
Pacific HiTech
will have just gotten a copy of the Slackware '96 CD with the September
edition of Mo' Linux. Pacific HiTech (PHT) has a VERY nice service which
offers a monthly CD full of all kinds of goodies including the most recent
kernel sources, new programs and updates from Sunsite's Incoming dir, the
latest GNU stuff including GCC and its accessories, and so forth. They take
special requests and have recently included things such as the huge Perl
archives, Tcl/Tk archives, Python archives, the Java Development Kit (JDK),
and so forth. Also, there are regular Red Hat RPM and SRPM updates each month
for those running Red Hat systems.
And keep in mind that Red Hat's Rembrandt just hit beta release! This is their
kernel 2.0 version and should be ready for regular release soon! You can get
a copy of Rembrandt beta at the
Red Hat WWW site
as well as find all kinds of nifty info and links in their "Linux
Info" page.
Since Christmas is just around the corner, I'm thinking about writing up a
small "Wish List" of tools and toys that you might want to put on
your Beloved's "Get For Me List". The small hoard of books and CD's
on the bookshelf is growing -- next month I'd like to do a short piece on
things that I've found useful. *YMMV.
*YMMV: "Your Mileage May Vary"
Here's the patch
for the sysklog bug in Slackware '96
Those of you who've just installed Slackware 3.1 may have run into
the same rather frustrating bug in the sysklog package that I
did. After a recent installation, I found that syslogd would dump core
after running pppd. About that time, postings to comp.os.linux.setup
and misc suggested that this was a problem with the distribution and not
with the hardware I was running.
So, after a request for help to Dr. Greg Wettstein, the maintainer of
the sysklog package, I received the following patch from him that remedied
the situation. For those of you needing this, you can get a copy of the
message which Greg sent. Just load it and save it to disk as a text file.
You'll also need a copy of the sysklog sources to recompile the program.
Here's what you'll need:
Sysklog patch from G. Wettstein (~70K)
MANY thanks to Greg W. and the rest of the folks who've worked on this
program.
I mentioned in the above announcement about StarOffice that you'll need a copy
of the motif libraries to run this product (at least while it is distributed
as shared-library executables). I really want to put in a good word for the
folks at Red Hat Software Inc. and for
their version of Red Hat Motif 2.0.
When I went to the Linux Expo '96 this past April, I had a seriously
fun time meeting folks, chatting, perusing the various book and vendor tables,
and sitting in on the various talks. If you missed it this past year and you
can drive, fly, Amtrak, run, jog, walk, or crawl your way to Raleigh, North
Carolina next Spring, then you won't want to miss it!! I don't know for sure
if they're planning another Expo, but if so, you really don't want to miss it.
Anyway, while I was there I bought a copy of Red Hat Motif 2.0 and have
been using it ever since. Now, I know that one of the FAQ's to the various
comp.os.linux.**** groups is "HELP! Which Motif should I get?!!", or
something to that effect. There usually ensues a modestly impassioned
discussion about the merits and drawbacks of one's recent Motif purchase.
For the record, I'd like to say that I've been extraordinarily pleased with
this product. It comes with a very complete User's Manual which covers
installation and configuring the Motif Window Manager (mwm). The CD also
contains the Motif libraries, development tools, and documentation in both
*.tar.gz format and as RPM's.
Installation was a breeze using rpm version 2.0 and I've been compiling motif
stuff without a hitch ever since. This includes programs such as mosaic,
plan, llnlXFtp, llnlXDir, xtar, xmcalendar, xmdiary, XEmacs, GVim, and so
forth. Compiling with the Motif libs has been completely transparent and
using shared, pre-compiled binaries (such as StarOffice) has been flawless.
At a time when there has been a LOT of negative press towards a variety of
individuals and institutions, let me offer a very heartfelt positive comment:
To the folks at Red Hat, thanks for a VERY nice product!
(FYI, I just got a copy of the most recent flyer from Surplus Direct, a
distributor of, you guessed it..., surplus hardware and software. On page 17
of the flyer they offer the Red Hat's MOTIF for LINUX V2.0 CD for
$99.99. Not a bad deal... :-) You can call them at 1-800-753-7877 U.S. or
541-387-6000 International. They even have a nifty web page which you can
check out at
http://www.surplusdirect.com)
OK, ready for a quiz...? Close your books, put away your notes, and answer the
following question:
Without looking at the man page, (a) What does the following command
do? and (b) Why on earth would you use it in the first place?
tar -tvzf file.tar.gz |tr -s ' ' |cut -d ' ' -f8 |less
Don't peek...!
(If this were a REAL web page, you'd click on a tiny icon of a
music box and have it do RealAudio of that jingle from Jeopardy while an
accompanied set of animated icons amuses you. But since I'm not that bright,
you'll have to hum quietly to yourself and decide when you're tired of
waiting... :-)
Figured it out?
If you guessed that it uses tar to do an archive listing on a tar'd and
GNU gzip'd archive, then you'd be warm.
If you guessed that it uses tar to do an archive listing on a tar'd and
GNU gzip'd archive and then piped the output to the GNU tr utility
which would translate multiple instances of the space character into a single
space character, then you'd be even warmer.
If you guessed that it uses tar to do an archive listing on a tar'd and
GNU gzip'd archive and then piped the output to the GNU tr utility
which would translate multiple instances of the space character into a single
space character and then pipe that output to the GNU cut utility
which would use that single space as a field delimiter and then print only the
data in field 8, then you'd be hot.
And if you guessed that it uses tar to do an archive listing
on a tar'd and GNU gzip'd archive and then piped the output to the GNU
tr utility which would translate multiple instances of the space
character into a single space character and then pipe that output
to the GNU cut utility which would use that single space as a
field delimiter and then print only the data in field 8 and then output
all of that to the less pager so that you could view, search, edit, and
optionally print the output, then you, my friend get to...
Go to the head of your class! :-)
Actually, I wouldn't have been able to guess this without peeking a bit, so
don't feel bad if you didn't guess all of it correctly. But this answer only
gives the answer to part (a). The real question you have to ask yourself is,
"Why on earth would you do this in the first place?"
Good question.
I'll get to that in a moment, but first, let me ask a simple question:
"How do you know what's actually inside a tar or tar+gzip archive
without actually unarchiving it?" Now, you can always unarchive a
tar.gz file and have a look at things but what if you really only wanted to
see what was in it or just look at a single file in the archive. What do you
do then?
The answer lies, at least in part, with our funky little command line above.
Let's see what we can do with this.
The first thing you've all probably realized is that tar has a bazillion or so
command line arguments so you can do almost anything with it. As you've
guessed, using the "-t" option displays a listing of the files in
the archive. If the archive has been compressed, then using the
"-z" option will automatically uncompress the archive.
So far, so good.
Thing is, what you want to do is actually look at one of the files in that
archive. Say you wanted to have a peek at the README file that came with some
program. Seems silly to have to unarchive an entire (potentially HUGE) file
just to see one item. Those of you who've used tar for a while will realize
where I'm going with this. You see, another one of tar's nifty little options
is the "-O" (which can also be invoked as --to-stdout) which causes
tar to send the output directly to standard output: generally, your computer
terminal. This is what we need to use to get a look at some file in the
archive -- we'll have tar send it to stdout so we can view it. That way, we
won't need to unarchive the file.
The other piece of the puzzle involves how you get tar to unarchive a specific
file within an archive. Again, you manual page readers will know that this is
done by simply appending the filename(s) to the end of the argument. Now in
case I'm starting to lose any of you, here's an example which should help
clear things up.
Say that I have some archive such as the a2ps program (which does ASCII
-> PostScript conversion, BTW). To get a listing of the files in the
archive all I have to do is:
tar -tvzf a2ps-4.5.23.src.tar.gz
and this gives me the following output:
drwxr-xr-x 11714/117 0 Sep 5 11:38 1996 a2ps-4.5.23/
-rw-r--r-- 11714/117 7721 Sep 5 11:38 1996 a2ps-4.5.23/INSTALL
-rw-r--r-- 11714/117 2281 Sep 5 11:38 1996 a2ps-4.5.23/README
-rw-r--r-- 11714/117 1429 Sep 5 11:38 1996 a2ps-4.5.23/TODO
-rwxr-xr-x 11714/117 4773 Sep 5 11:38 1996 a2ps-4.5.23/install-sh
-rw-r----- 11714/117 3576 Sep 5 11:38 1996 a2ps-4.5.23/Makefile.in
-rw-r--r-- 11714/117 907 Sep 5 11:38 1996 a2ps-4.5.23/config.h.in
-rwxr-xr-x 11714/117 47767 Sep 5 11:38 1996 a2ps-4.5.23/configure
-rw-r----- 11714/117 1415 Sep 5 11:38 1996 a2ps-4.5.23/configure.in
-rw-r--r-- 11714/117 81240 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.c
-rw-r----- 11714/117 70081 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.h
-rw-r--r-- 11714/117 15348 Sep 5 11:38 1996 a2ps-4.5.23/afm.h
-rw-r--r-- 11714/117 10482 Sep 5 11:38 1996 a2ps-4.5.23/a2ps.man
So now, let's say that I want to have a look at what's in the README or the
INSTALL file; well, now that you know that you send the output of tar to
stdout you know you're golden! All you'd need to do is something like:
tar -xvzOf a2ps-4.5.23.src.tar.gz a2ps-4.5.23/README
And, voila!, there's your file. The astute will immediately comment
that piping that output to a pager such as more or less
makes a lot more sense because now you can actually read more than just the
last screen full of text.
Note, too, that the basic command line was (in pseudocode):
tar -options archive.tar.gz path/fileToView
Notice that you have to include the "a2ps-4.5.23/" portion and NOT
just the name of the file.
So, now we're getting somewhere!
You can use the tar -tvzf FILENAME.tar.gz command line to get a
directory listing of a tar archive and then use something like:
tar -xvzOf a2ps-4.5.23.src.tar.gz a2ps-4.5.23/README |less
to actually view the file -- the tar file is intact, nothing is unarchived to
disk, and you fingers never leave your hand!
And now, let's pick up on our original question once again. Here's where that
funky little command line becomes useful to use once again.
Those of you who've done a bit of shell programming know that, fundamentally,
every programmer is lazy at heart. That is to say, shell scripts are a VERY
convenient way of saving yourself the bother of typing the same commands over
and over again -- and this is one of those places where this is handy.
Now that you know how to view a file from within a tar file without ever
unarchiving the entire file, wouldn't it be handy to set up a shell script to
do just that...?
You know I wouldn't have asked this if I didn't already have an answer in
mind... eh?
Well, this is one of those things that I've started toying around with in the
past couple days and while I haven't gotten anything written yet, that nifty
little tar command at the top is part of the solution. You see, it would be
quite handy to be able to do a listing of a tar archive, select one or more of
the files, and then view them. The thing is, as I mentioned before, you have
to give tar the full name of the file you wish to view -- including any path
information. That is, if you'd tried to do:
tar -xvzOf a2ps-4.5.23.src.tar.gz README |less
you'd have gotten an error message because there's no README file in the
archive -- there is the file a2ps-4.5.23/README. See the difference?
You have to have the a2ps-4.5.23/ prefix for tar to work correctly.
So, can you think of a way to take the output of tar -- the file listing --
and generate a listing of just the filenames which you can pass back to tar.
Again, remember that it has to include the entire path+name but cannot be the
entire line, such as:
-rw-r--r-- 11714/117 2281 Sep 5 11:38 1996 a2ps-4.5.23/README
Somehow, we've got to strip away all the leading stuff and get only to the
a2ps-4.5.23/README entry. So let's cut to the chase.
One way to do this is using the method I mentioned above: using tar with the
"-t" option displays a file listing. Next, you can use cut
to access a single a column of data because, as you've all noticed, there are
8 fields of information in the above listing:
PERMISSIONS GROUP/USER SIZE MONTH DAY HR:MIN YEAR PATH/FILENAME
Now, you'll also notice that these are separated by a space and so you should
be able to use this as a field separator. But if you try something like:
tar -tvzf a2ps-4.5.23.src.tar.gz |cut -d ' ' -f8
what you end up with is:
7721
2281
1429
4773
3576
Sep
1415
Sep
Sep
Sep
Sep
So what went wrong!?
Well, we used a space character as the field delimiter which was the correct
thing to do. But have a look at the actual file listing. Notice that there
is a single space between most, but not all, of the fields. Between
the group/user field and the size field there is a variable number of spaces
and there appears to be two spaces between SEP and 5. So, cut
dutifully used a single space character as the field separator, but the
result wasn't' what we expected.
Hmmm... now what...?
Well, there's another little mentioned but VERY useful utility called
tr. It's a seriously handy little item that does, among other things,
character translation. In this case, we can use it to truncate a
series of one or more spaces into a single space (and THEN, cut should work
correctly!).
Now, is the light dawning? :-)
We use tar to get the file listing, tr to truncate all the extraneous spaces
into a single space character, and then pipe the whole thing through cut to
get just the fields that we want. Doing this on the a2ps file, we get:
a2ps-4.5.23/
a2ps-4.5.23/INSTALL
a2ps-4.5.23/README
a2ps-4.5.23/TODO
a2ps-4.5.23/install-sh
a2ps-4.5.23/Makefile.in
a2ps-4.5.23/config.h.in
a2ps-4.5.23/configure
a2ps-4.5.23/configure.in
a2ps-4.5.23/a2ps.c
a2ps-4.5.23/a2ps.h
a2ps-4.5.23/afm.h
a2ps-4.5.23/a2ps.man
Pretty slick, eh?
Now, we can pick any of these entries and if we pass them to tar using the
"-O" option then the file gets printed to stdout. Pipe this output
to less and we're golden!
A tar file viewer!
So why mention all of this?
Well, first, because I'm toying around with ideas for a shell script that will
do just this -- write a small program that will let me view individual files
from a tar.gz archive. I've got a couple ideas floating around and may try
using the dialog program for a console UI, or I might just go ahead and
try this using tcl/tk.
Second, I do this to point out one of the beauties of using Linux (or any UNIX
type OS) and that is the use of pipes to connect any number of the myriad of
utilities together into a powerful command. Using four programs and a bunch of
pipes, we've seen how we can easily ready any file within a tar archive
without having to uncompress the entire thing.
That is seriously cool!
Anyway, I've just started playing with this. Let me quickly mention, for
those of you who already know and are waving your cyberhands in the air, that
there is a very easy way to manipulate tar.gz files already -- and it's
with a program that MOST Linux distributions already install: Midnight
Commander.
I cannot say enough good things about this program. I'm honestly not much of
a file manager type user -- I really do prefer the command line for most file
and directory operations. But, mc is different. I have absolutely fallen in
love with this. It's very well designed, is quite mature, has a boatload of
nifty features, AND it'll let you easily view and copy files from a tar.gz
archive using its VFS (virtual file system).
I've been wanting to do a write up on MC now for, quite literally, months and
just haven't had the time to write a decent article -- one that really does it
justice. Anyway, for those of you who are interested, all you have to do to
access a tar.gz file is fire up mc, select the tar.gz file and either double
click on it (if you're running gpm and have mouse support) or hit RETURN and
it'll automatically unarchive the file into a VFS from which you can browse
the archive just as though it were installed on your harddrive.
The other application that'll let you do this is the xtar program -- a
motif based app that I recently came across at the ftp.x.org archive. I
honestly haven't seen this at sunsite or tsx-11 and I don't know that I've
seen it any of the usual Linux distributions either. It's a VERY nice little
app that let's you browse and view tar.gz archives.
Anyway, try out mc or xtar if you want tar.gz browsing right now. But, let's
see if we can't figure out a way to do something like this using shell
scripting or tcl/tk. I'll let the interested work on this and, if I have any
successes myself, I'll write this up in next month's issue.
Til then, Happy Scripting!
OK, quick question:
Can you name 5 tools or utilities which you can use to get information about a
file?
I'm sure you can if you give it a bit of thought. You see, most of the time,
if you've installed a system yourself then you have a pretty good idea about
what's on it and (hopefully...) where things are. But what if you come across
a cryptically named file (Hmmm... fancy that on a UNIX system... :-) in your
/usr/bin directory and want to get a bit of information about it. Or, what if
you know what it is that you're looking for, but just can't find it!
Ok, so let's talk about a couple tools you can work with to get basic file
information.
The one's that I was thinking about included:
- ls
- file
- type & which
- find & locate
- ldd
Now, there are others, I'm sure, but these five basic utilities (seven if
you count similar ones) will go quite a ways towards helping you get a handle
on what's on your system.
A look at ls
Anyone's who's used Linux for more than..., Hmmm... about a day or so, has run
across ls which does a directory listing. And, if you've ventured a
peek at its manual page, your first reaction may have been one of incredulity
at the bewildering number of command line options. Fear not. You really only
need a couple of these on a routine basis (these are your friends) and the
rest of these let you do all kinds of groovy and interesting things when you
have nothing else to do but play with your directory listings (these are you
great Aunt Fanny's half-sister's double cousin, twice removed... you know
they're around, you just have no earthly idea as to what they do).
So, you know that if you want to get basic information about a file, then the
best place to start is with a directory listing. Using the "-l"
option gives you a long listing which includes the file type (regular,
directory, fifo, block, and so forth), number of hard links, user name, group
name, size in bytes, timestamp (generally, the modification time), and the
file name itself.
You also know, I'm sure, that adding the "-a" displays all
files, including all the so-called dot-files which begin with a period (.) and
which are normally not displayed in a directory listing.
Many Linux distributions also configure ls to use the "-F" option
which print a suffix after each file to indicate what its basic type is:
- "*" for regular files which are executable
- "/" for directories
- "@" for symbolic links ("symlinks")
- "|" for FIFO's ("pipes" or "First In
First Out")
- "=" for sockets
- nothing for regular files
So, just using humble 'ol ls can give you quite a bit of information about
your files. A couple of the more useful things that you can do with ls
include using the "-t" option which sorts the directory contents by
time. This is very useful if you happen to be in a directory such as /usr/bin
that has a LOT of files and you're looking for something which you've recently
added but can't recall the name. Using "ls -lt" causes all the
newest files to, as it were, rise to the top of the list. If, however, you
want to list the latest files last, no problem, mon, just add the
"-r" option to the soup and you'll get a reversed listing by
time (i.e., "ls -ltr").
Yet another handy little option will let you find out when a file's
status was last changed. The status includes things such as owner or
group information or permissions. You can change these things without
actually modifying the file itself. Generally, the time stamp indicates when
a file was last modified, but if what you want to see is when a file's
status was last changed, then use the "-c" option. Now, if
you're wondering whether permissions or user/group information has been
changed recently, then use "ls -ltrc" command to display the files
which have changed status most recently at the end of the listing.
Those are just a few of the things that you can do with ls. So, if you're
stuck at home on some rainy Saturday afternoon and are tired of the Laverne
And Shirley reruns, go amuse yourself -- read the ls manual page, write
down all the options, and try them all out. At least there won't be
commercial interruptions... :-)
Using file
Besides using ls with the "-F" option, there's another very
handy utility called file which gives you a indication of what a file
actually is.
Every now and then, someone posts a message to one of the comp.os.linux groups
asking about how they can determine whether a file is a.out or ELF (or
something else, for that matter). If you really do have a mysterious file,
then file is the utility for you.
So, let's say that you've come across a file in your /usr/local/bin directory
called "d2utxt" and it beats the pants off of you what this thing
is. Well, you could try something like:
file /usr/local/bin/d2utxt
I've actually got that file on my system and when I run this (from within VIM
of course -- notice that my fingers never leave my hand... :-) I get:
/usr/local/bin/d2utxt: Linux/i386 executable or impure executable (OMAGIC)
OK, that lets me know that it's some kind of executable. So is it ELF or not?
Well, let's run this on a file which I know is ELF and see what happens:
file /usr/bin/vi
/usr/bin/vim: ELF 32-bit LSB executable i386 (386 and up) Version 1
So, there's your answer! It seems that the d2utxt program was, in fact, a.out
format and vim is in our now familiar ELF format. So, if you're wondering
what kind of executable format a file is in, this is your solution. And keep
in mind that file recognizes a LOT more than simply executables. As an
exercise, try running it on a plain text file, a shell script, a *.dvi file, a
postscript file, a shared library file, and so forth. I won't go into the
specifics of how file works its magic (no pun intended... honest!) but if
you're interested, the manual page gives those details.
Keep in mind that the file utility is a VERY useful tool to
have at your disposal when you're writing shell programs that depend
on knowing what a file's type is.
For example, suppose that you decide to write a shell script to
automate file printing. One of the things that your script will need
to know is what type of file you are working with. Tex, DVI,
PostScript, and plain text files get printed using quite different
programs. Here's an ideal situation in which the file program
will give you that information.
Again, convince yourself of this by running file against several
different file formats -- pretty impressive, eh?
Finding Executables with type & which
The next bit of information about a file that can often be quite useful is
a rather simple one: "Where is it??!!"
If you're trying to find an executable then this task is greatly eased by use
of either which or type (if you're using the BASH shell).
Either one of these will print the path to a give executable -- assuming, that
is, that it is in your PATH statement. So, let's say that you wanted to find
out where xdvi was located. Now, you could probably guess, but let's just say
that you really were clueless and wanted to know. Well, if you tried
something like the following you could find out:
which xdvi
/usr/X11/bin/xdvi
type xdvi
xdvi is /usr/X11/bin/xdvi
Hmmm... that was pretty easy now, wasn't it? Both of these found our file in
the /usr/X11/bin/ directory and the output was pretty similar. But before we
call this an even draw, suppose that you try to do something like this:
type tarx
tarx is aliased to `tar -xvzf'
type exec
exec is a shell builtin
Hmmm... interesting.
I won't give you the output that happens when I run which on either of
these because what happens is it prints an error message that states that it
couldn't find it in... and then prints the entire search PATH. I'll
let you try this one at home. Suffice it to say that if you're running the
BASH shell, then using type gives you the added benefit of recognizing
shell aliases and builtins in addition to executables.
Very handy.
Another useful little item that type can do for you is find
duplicate executables. Now before you go scoffing, consider the fact
that it is VERY easy to do a bit of "Do-It-Yourself" system
upgrading and install a few programs. If you don't know that the program
which you are installing has already been installed (but in a different
directory) then you end up with two copies. So which one gets executed?
Good question.
Presuming that you don't use absolute path names for executables
(e.g./usr/bin/vim) every time you want to start a program, then
whichever executable is found first in your PATH statement. So, if you have
two copies of elvis (one from an original installation and one from a
new compile and install) then the one that is found first is executed.
And how, do you suppose, I know this...?
Believe me, I've done it :-)
And the results can be impressively frustrating.
Specifically, I had upgraded a version of Tcl/Tk a while back and when I ran
all my favorite tcl/tk apps I started getting weird messages about version
incompatibilities and so forth. So I recompiled and reinstalled and
still got those annoying error messages. It was driving me crazy.
Finally, I tried running type and noticed that the wish
executable wasn't where I thought I'd installed it. The breakthrough came when
I tried:
type -a wish
wish is /usr/local/bin/wish
wish is /usr/bin/wish
Ah Ha!!
You see, there had been an old copy of a previous version lying around and I
had simply forgotten to delete/rename it. The old version was being found
first but it was incompatible with the tcl scripts I was using. Renaming the
old version cleared things up.
So the moral of the story is that if want to ensure that you have only one
copy of a program in the search PATH, then use type -a.
Finding Files with find & locate
OK, so now you know how to find executables... what if what you're looking for
is NOT an executable? What then?
Well, these next two utilities deserve an entire article (and, in fact, got
just that in one of the recent issues of the
Linux Journal. Both find and locate will allow you to
search anywhere in your system for a given file. For the time being, I'm
going to use a simple example.
Suppose that I'm looking for a certain configuration file for the lynx
program. I've discovered that lynx has a config file that will let me set
various options -- but I don't know where this is located except that I have
a hunch that it is somewhere in /usr/local/. Great! To find it, all we have
to do is:
find /usr/local -name lynx* -print
/usr/local/bin/lynx
/usr/local/lib/lynx
/usr/local/lib/lynx/lynx.cfg
/usr/local/lib/lynx/lynx.hlp
/usr/local/lib/lynx/lynx.man
/usr/local/lib/lynx/lynx_help_main.html
/usr/local/lib/lynx.cfg
/usr/local/lib/lynx.cfg.color
/usr/local/man/man1/lynx.1
/usr/local/src/INSTALLED/lynx2-5FM.color.ELF.tgz
/usr/local/src/Incoming/lynx2-6.tar.gz
/usr/local/src/Incoming/lynx2-6.color.ELF.tgz
/usr/local/doc/lynx
Yow! Bonanza!
So there we go... find not only located our lynx configuration file but
also found that there were duplicates! Interesting :-) So how do we do this
for any file? Well, the basic pattern is:
find -name -print
That is, the first argument is the directory from which to START looking.
Find will automatically traverse all the subdirectories beneath this. So, if
you wanted to scour your entire system, you just invoke find as:
find / -name lynx* -print
The second argument is "-name" followed by the pattern of the file
name you're looking for. And finally, the "-print" option specifies
that find should print the results to stdout. Keep in mind, though, that the
GNU version of find doesn't need the "-print" option -- it defaults
to printing to standard out (your terminal :-).
The other handy-dandy little tool is locate. If this has been set up
correctly (that is, that the database of files is routinely updated) then it
is a LOT faster to use than find if all you are looking for is a particular
file name!
To use it just invoke it as:
locate lynx
/home/fiskjm/.lynx-bookmarks
/home/fiskjm/.lynxrc
/usr/bin/lynx
/usr/doc/lynx
/usr/doc/lynx/about_lynx
/usr/doc/lynx/about_lynx/about_lynx-dev.html.gz
/usr/doc/lynx/about_lynx/about_lynx.html.gz
/usr/doc/lynx/about_lynx/COPYHEADER.gz
/usr/doc/lynx/about_lynx/COPYING.gz
/usr/doc/lynx/CHANGES.gz
/usr/doc/lynx/CHANGES2-3.gz
/usr/doc/lynx/CHANGES2-4.gz
/usr/doc/lynx/CMU.announce.gz
/usr/doc/lynx/CRAWL.announce.gz
/usr/doc/lynx/DESC.gz
/usr/doc/lynx/docs
/usr/doc/lynx/docs/README.html.gz
/usr/doc/lynx/docs/README.txt.gz
/usr/doc/lynx/docs/RFC-MAILCAP.txt.gz
/usr/doc/lynx/FM.announce.gz
/usr/doc/lynx/IBMPC-charsets.announce.gz
/usr/doc/lynx/INSTALLATION.gz
/usr/doc/lynx/lynx_help
/usr/doc/lynx/lynx_help/keystroke_commands
/usr/doc/lynx/lynx_help/keystroke_commands/bookmark_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/dired_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/edit_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/gopher_types_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/history_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/keystroke_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/movement_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/option_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/other_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/print_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/scrolling_help.html.gz
/usr/doc/lynx/lynx_help/keystroke_commands/xterm_help.html.gz
/usr/doc/lynx/lynx_help/lynx_help_main.html.gz
/usr/doc/lynx/lynx_help/Lynx_users_guide.html.gz
/usr/doc/lynx/PROBLEMS.gz
/usr/doc/lynx/README.gz
/usr/doc/lynx/RELEASE_STATEMENT.gz
/usr/doc/lynx/samples
/usr/doc/lynx/samples/jumpsUnix.html.gz
/usr/doc/lynx/samples/jumpsVMS.html.gz
/usr/doc/lynx/samples/lynx.cfg.gz
/usr/doc/lynx/samples/lynx.com.gz
/usr/doc/lynx/samples/mailcap.gz
/usr/doc/lynx/samples/mime.types.gz
/usr/doc/lynx/SOCKETSHR.announce.gz
/usr/doc/lynx/TCPWARE.announce.gz
/usr/doc/lynx/userdefs.h.gz
/usr/doc/lynx/VMSWAIS.announce.gz
/usr/lib/lynx
/usr/lib/lynx/lynx.cfg
/usr/lib/lynx/lynx.hlp
/usr/local/bin/lynx
/usr/local/doc/lynx
/usr/local/doc/lynx/LynxUser.guide.gz
/usr/local/lib/lynx
/usr/local/lib/lynx.cfg
/usr/local/lib/lynx.cfg.color
/usr/local/lib/lynx/keystroke_commands
/usr/local/lib/lynx/keystroke_commands/bookmark_help.html
/usr/local/lib/lynx/keystroke_commands/dired_help.html
/usr/local/lib/lynx/keystroke_commands/gopher_types_help.html
/usr/local/lib/lynx/keystroke_commands/history_help.html
/usr/local/lib/lynx/keystroke_commands/keystroke_help.html
/usr/local/lib/lynx/keystroke_commands/movement_help.html
/usr/local/lib/lynx/keystroke_commands/option_help.html
/usr/local/lib/lynx/keystroke_commands/other_help.html
/usr/local/lib/lynx/keystroke_commands/print_help.html
/usr/local/lib/lynx/keystroke_commands/scrolling_help.html
/usr/local/lib/lynx/keystroke_commands/xterm_help.html
/usr/local/lib/lynx/lynx.cfg
/usr/local/lib/lynx/lynx.hlp
/usr/local/lib/lynx/lynx.man
/usr/local/lib/lynx/LynxStartFile.html
/usr/local/lib/lynx/lynx_help_main.html
/usr/local/lib/lynx/Lynx_users_guide.html
/usr/local/lib/lynx/new_installs.html
/usr/local/lib/lynx/readme.html
/usr/local/man/man1/lynx.1
/usr/local/src/Incoming/lynx2-6.color.ELF.tgz
/usr/local/src/Incoming/lynx2-6.tar.gz
/usr/local/src/INSTALLED/lynx2-5FM.color.ELF.tgz
/usr/man/man1/lynx.1.gz
/var/log/packages/lynx
/var/X11R6/lib/config/lynx.cf
YIKES!!
On my system, this took about 1 second to display and it printed the location
of EVERY instance of "lynx". Now, for some reason which I haven't
figured out yet why this doesn't work the way the manual page indicates that
it should. Maybe your system works better than mine... :-)
The way that it should work is that you give locate a filename
pattern which it searches for. Such as:
locate lynx*
However, when I tried this on my system, it simply returned nothing. Using
locate lynx worked like a charm.
Got me.
Keep in mind, too, that find is a seriously powerful search tool that
has all kinds of options that let you do sophisticated searches. You really
do need to check out the article that recently appeared in the Linux Journal.
I'm sorry that I can't recall offhand which issue it was in, but the LJ has
put a number of articles online on the Web and so you might try looking at
their web site for information.
Finding Shared Library Information with ldd
Finally, here's a nifty little trick that let's you see what shared libraries
a file is linked against. If you've ever wondered whether a file was
statically or dynamically linked, then here's your answer!
Just invoke ldd with the name of the executable and it will print out a
listing of all the libraries that it is linked against AND where these
libraries are located on your system.
So, for example, running ldd against gvim (Graphical VIM), I get the
following output:
libXm.so.2 => /usr/X11R6/lib/libXm.so.2
libXt.so.6 => /usr/X11R6/lib/libXt.so.6
libSM.so.6 => /usr/X11R6/lib/libSM.so.6
libICE.so.6 => /usr/X11R6/lib/libICE.so.6
libXext.so.6 => /usr/X11R6/lib/libXext.so.6
libX11.so.6 => /usr/X11R6/lib/libX11.so.6
libncurses.so.3.0 => /lib/libncurses.so.3.0
libc.so.5 => /lib/libc.so.5.3.12
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4
pretty nifty, eh?
Anyway, if you've ever picked up a pre-compiled binary and it just simply won't
execute, try running ldd against it to ensure that all the needed libraries
are being found.
So, that should do it!
I'm sure that there are many other tricks and means for prying information out
of an obscure file. As a parting note, if you've ever wondered just exactly
what a file does then you can try a couple things. The first is to see
whether there is a manual page for the program. That's usually a good source
of information. The other maneuver you can try is simply something like:
prog --help
Presuming the program's name was "prog", then frequently using a
command line option such as "--help" will print a help message.
Also, a number of programs will, if they don't recognize a command line
option, go ahead and print a short usage statement anyway. If you're in the
dark, give it a whirl!
If you'd like,
drop me a note at:
John M. Fisk
<fiskjm@ctrvax.vanderbilt.edu>
Version Information:
$Id: issue11.html,v 1.1.1.1 1997/09/14 15:01:36 schwarz Exp $
Copyright © 1996 Specialized Systems Consultants, Inc.
For information regarding copying and distribution of this material see the
Copying License.
The Back Page
Contents:
Larry Ayers
Larry Ayers lives on a small farm
in northern Missouri, where he is currently engaged in building a
timber-frame house for his family. He operates a portable band-saw mill,
does general woodworking, plays the fiddle and searches for rare
prairie plants, as well as growing shiitake mushrooms. He is also
struggling with configuring a Usenet news server for his local ISP.
Earl Brown
Earl Brown has been involved in the Internet for 4 or 5 years, and got into
Unix when he realized that Unix helped start the Internet and
that it is the future of the Internet, as well. He loves LINUX as an
operating system, because "The fact that it's free doesn't hurt, but the
important thing is that I think it's the best OS out there." He is a
computer programmer, an Internet specialist. He has fantasies/dreams
about becoming a writer and a college teacher. For more of his work, see
http://www.lvinet.com/~gleep/CompKnow/CompIdx.htm. His personal web page
can be found at http://www.enol.com/~gleep/.
John M. Fisk
John Fisk is most noteworthy as the former editor of the Linux Gazette.
After three years as a General Surgery resident and
Research Fellow at the Vanderbilt University Medical Center,
John decided to "hang up the stethoscope", and pursue a
career in Medical Information Management. He's currently a full
time student at the Middle Tennessee State University and hopes
to complete a graduate degree in Computer Science before
entering a Medical Informatics Fellowship. In his dwindling
free time he and his wife Faith enjoy hiking and camping in
Tennessee's beautiful Great Smoky Mountains. He has been an avid Linux fan,
since his first Slackware 2.0.0 installation a year and a half
ago.
Michael J. Hammel
Michael J. Hammel,
is a transient software engineer with a background in
everything from data communications to GUI development to Interactive Cable
systems--all based in Unix. His interests outside of computers
include 5K/10K races, skiing, Thai food and gardening. He suggests if you
have any serious interest in finding out more about him, you visit his home
pages at http://www.csn.net/~mjhammel. You'll find out more
there than you really wanted to know.
Phil Hughes
Phil Hughes is the publisher of Linux Journal, and thereby Linux
Gazette. As an employer, Phil is "Vicious, Evil,
Mean, & Nasty, but kind of mellow" as a boss should be.
He dreams of permanently tele-commuting from his home on the
Pacific coast of the Olympic Peninsula.
Thanks to all our authors, not just the ones above, but also those who wrote
giving us their tips and tricks and making suggestions. Thanks also to our
new mirror sites.
Since I've chosen to celebrate Halloween in this issue, I'll include
a few Halloween and weird links in hopes that they will not disappear on November 1.
- YABOO A YAHOO parody
page with only Halloween links. Some neat links to Halloween history, ghost
stories, etc.
- Virtual Jack-0-Lantern
Have fun creating your own virtual jack-o-lantern.
- Virtual Haunted House
Looked interesting, but not open until October 31. Check it out.
- Forest J. Ackerman of
monster and "Sci Fi" movies has a very weird site indeed.
- The Island of Dr. Moreau movie
site.
- Halloween Mystery
Billed as an interactive MUD-like page, this turned out to be a
game that you play following text instructions and story-line to solve a
mystery.
- Discworld is
not exactly Halloween, but is definitely weird and fun. Another MUD game
based on Terry Pratchett's fantasy novels.
If you would like some personal information about me, clicking on my
name below will take you to my home page. It's getting jazzier by the moment.
Marjorie L. Richardson
Editor, Linux Gazette gazette@ssc.com
Linux Gazette, http://www.ssc.com/lg/
This page written and maintained by the Editor of Linux Gazette,
gazette@ssc.com
SSC - Publishers of
Linux Journal
The Mailbag! 
Date: Sun, 29 Sep 1996 01:46:02 -0700 
More 2¢ Tips!
Another XTerm
Titlebar Trick
Comdex Conference
And
Just What Is the Linux Weekend Mechanic...?
The Talk About Town...
More tar Tricks!
