End of archive" >> $INDEX echo "" >> $INDEX fi ---- attachment [2] /****************************************************************************** Reads stdin. Assuming that this has a mailfile format, it breaks the input in single messages. A filestem must be given as argument, and single messages will be written as filestem.1 filestem.2 etc. (c) 1997 I.Saviane ******************************************************************************/ #define NMAX 256 /*****************************************************************************/ #include
This is some plain text
_HEAD1(`This is a main heading')
This is some more plain text
_TRAILER
The format is simple - just HTML code but you can now include files
and add macros rather like in C. I use a convention that my new macros
are in capitals and start with "_" to make them stand out from HTML
language and to avoid name-space collisions.
The m4 file is then processed as follows to create an .html file e.g.
m4 -P
m4_divert(-1)
m4_define(`_H1_num',0)
m4_define(`_H2_num',0)
m4_define(`_H3_num',0)
m4_define(`_H4_num',0)
m4_divert(1)')
m4_define(_H1, `m4_divert(-1)
m4_define(`_H1_num',m4_incr(_H1_num))
m4_define(`_H2_num',0)
m4_define(`_H3_num',0)
m4_define(`_H4_num',0)
m4_define(`_TOC_label',`_H1_num. $1')
m4_divert(0) ')
One restriction is that you should not use diversions within your
text, unless you preserve the diversion to file 1 used by this TOC
generator.
Contents
3.8 Simple tables
Other than Tables of Contents, many browsers support tabular
information. Here are some funky macros as a short cut to producing
these tables. First, an example of their use:
![[Linux Information]](_HOMEPAGE/gif/powered.gif)
')
Note the careful use of quotes to prevent the variable _LOCAL from
being expanded. _HOMEPAGE takes on different values according to
whether the variable _LOCAL is defined or not. This can then ripple
through the entire project as you make the pages.
In this example, _PLUG is a macro to advertise Linux. When you are
testing your pages, you use the local version of _HOMEPAGE. When you
are ready to upload, you can remove or comment out the _LOCAL
definition like this:
m4_dnl m4_define(`_LOCAL')
... and then re-make.
Contents
3.3 Creating new text styles
Styles built into HTML include things like for emphasis and
for citations. With m4 you can define your own, new styles like
this:
m4_define(`_MYQUOTE',
$1
)
If, later, you decide you prefer instead of it is a
simple matter to change the definition and then every _MYQUOTE
paragraph falls into line with a quick make.
The classic guides to good HTML writing say things like "It is
strongly recommended that you employ the logical styles such as
... rather than the physical styles such as ... in
your documents." Curiously, the WYSIWYG editors for HTML generate
purely physical styles. Using these m4 styles may be a good way to
keep on using logical styles.
Contents
3.4 Typing and mnemonic aids
I don't depend on WYSIWYG editing (having been brought up on troff)
but all the same I'm not averse to using help where it's available.
There is a choice (and maybe it's a fine line) to be made between:
and:
_CODE(Some code you want to display.)
In this case, you would define _CODE like this:
m4_define(`_CODE',
Some code you want to display.
)
Which version you prefer is a matter of taste and convenience although
the m4 macro certainly saves some typing and ensures that HTML codes
are not interleaved. Another example I like to use (I can never
remember the syntax for links) is:
m4_define(`_LINK', $2)
Then,
Click here to get to SOMEWHERE
becomes:
_LINK(`URL_TO_SOMEWHERE', `Click here to get to SOMEWHERE')
Contents
3.5 Automatic numbering
m4 has a simple arithmetic facility with two operators m4_incr and
m4_decr which act as you might expect - this can be used to create
automatic numbering, perhaps for headings, e.g.:
m4_define(_CARDINAL,0)
m4_define(_H, `m4_define(`_CARDINAL',
m4_incr(_CARDINAL))$1_CARDINAL.0 $1
')
_H(First Heading)
_H(Second Heading)
This produces:
1.0 First Heading
2.0 Second Heading
Contents
3.6 Automatic date stamping
For simple, datestamping of HTML pages I use the m4_esyscmd command to
maintain an automatic timestamp on every page:
This page was updated on m4_esyscmd(date)
which produces:
This page was last updated on Fri May 9 10:35:03 HKT 1997
Of course, you could also use the date, revision and other facilities
of revision control systems like RCS or SCCS, e.g. $Date$.
Contents
3.7 Generating Tables of Contents
Using m4 allows you to define commonly repeated phrases and use them
consistently - I hate repeating myself because I am lazy and because I
make mistakes, so I find this feature absolutely key.
A good example of the power of m4 is in building a table of contents
in a big page (like this one). This involves repeating the heading
title in the table of contents and then in the text itself. This is
tedious and error-prone especially when you change the titles. There
are specialised tools for generating tables of contents from HTML
pages but the simple facility provided by m4 is irresistable to me.
3.7.1 Simple to understand TOC
The following example is a fairly simple-minded Table of Contents
generator. First, create some useful macros in stdlib.m4:
m4_define(`_LINK_TO_LABEL', $1)
m4_define(`_SECTION_HEADER', $1
)
Then define all the section headings in a table at the start of the
page body:
m4_define(`_DIFFICULTIES', `The difficulties of HTML')
m4_define(`_USING_M4', `Using m4')
m4_define(`_SHARING', `Sharing HTML Elements Across Several Pages')
Then build the table:
Finally, write the text:
.
.
_SECTION_HEADER(_DIFFICULTIES)
.
.
The advantages of this approach are that if you change your headings
you only need to change them in one place and the table of contents is
automatically regenerated; also the links are guaranteed to work.
Hopefully, that simple version was fairly easy to understand.
Contents
3.7.2 Simple to use TOC
The Table of Contents generator that I normally use is a bit more
complex and will require a little more study, but is much easier to
use. It not only builds the Table, but it also automatically numbers
the headings on the fly - up to 4 levels of numbering (e.g. section
3.2.1.3 - although this can be easily extended). It is very simple to
use as follows:
1. Where you want the table to appear, call Start_TOC
2. at every heading use _H1(`Heading for level 1') or _H2(`Heading
for level 2') as appropriate.
3. After the very last HTML code (probably after ), call
End_TOC
4. and that's all!
The code for these macros is a little complex, so hold your breath:
m4_define(_Start_TOC,`
_TOC_label
')
.
.
[definitions for _H2, _H3 and _H4 are similar and are
in the downloadable version of stdlib.m4]
.
.
m4_define(_End_TOC,`m4_divert(0)')
m4_define(`_Table_Hdr_Item', `
)
Contents
4. m4 gotchas
Unfortunately, m4 is not unremitting sweetness and light - it needs
some taming and a little time spent on familiarisation will pay
dividends. Definitive documentation is available (for example in
emacs' info documentation system) but, without being a complete
tutorial, here are a few tips based on my fiddling about with the
thing.
4.1 Gotcha 1 - quotes
m4's quotation characters are the grave accent ` which starts the
quote, and the acute accent ' which ends it. It may help to put all
arguments to macros in quotes, e.g.
_HEAD1(`This is a heading')
The main reason for this is in case there are commas in an argument to
a macro - m4 uses commas to separate macro parameters, e.g. _CODE(foo,
bar) would print the foo but not the bar. _CODE(`foo, bar') works
properly.
This becomes a little complicated when you nest macro calls as in the
m4 source code for the examples in this paper - but that is rather an
extreme case and normally you would not have to stoop to that level.
Contents
4.2 Gotcha 2 - Word swallowing
The worst problem with m4 is that some versions of it "swallow" key
words that it recognises, such as "include", "format", "divert",
"file", "gnu", "line", "regexp", "shift", "unix", "builtin" and
"define". You can protect these words by putting them in m4 quotes,
for example:
Smart people `include' Linux in their list
of computer essentials.
The trouble is, this is a royal pain to do - and you're likely to
forget which words need protecting.
Another, safer way to protect keywords (my preference) is to invoke m4
with the -P or --prefix-builtins option. Then, all builtin macro names
are modified so they all start with the prefix m4_ and ordinary words
are left alone. For example, using this option, one should write
m4_define instead of define (as shown in the examples in this
article).
The only trouble is that not all versions of m4 support this option -
notably some PC versions under M$-DOS. Maybe that's just another
reason to steer clear of hack code on M$-DOS and stay with Linux!
Contents
4.3 Gotcha 3 - Comments
Comments in m4 are introduced with the # character - everything from
the # to the end of the line is ignored by m4 and simply passed
unchanged to the output. If you want to use # in the HTML page then
you would need to quote it like this - `#'. Another option (my
preference) is to change the m4 comment character to something exotic
like this: m4_changecom(`[[[[') and not have to worry about `#'
symbols in your text.
If you want to use comments in the m4 file which do not appear in the
final HTML file, then the macro m4_dnl (dnl = Delete to New Line) is
for you. This suppresses everything until the next newline.
m4_define(_NEWMACRO, `foo bar') m4_dnl This is a comment
Yet another way to have source code ignored is the m4_divert command.
The main purpose of m4_divert is to save text in a temporary buffer
for inclusion in the file later on - for example, in building a table
of contents or index. However, if you divert to "-1" it just goes to
limbo-land. This is useful for getting rid of the whitespace generated
by the m4_define command, e.g.:
m4_divert(-1) diversion on
m4_define(this ...)
m4_define(that ...)
m4_divert diversion turned off
Contents
4.4 Gotcha 4 - Debugging
Another tip for when things go wrong is to increase the amount of
error diagnostics that m4 emits. The easiest way to do this is to add
the following to your m4 file as debugging commands:
m4_debugmode(e)
m4_traceon
.
.
buggy lines
.
.
m4_traceoff
Contents
5. Conclusion
"ah ha!", I hear you say. "HTML 3.0 already has an include statement".
Yes it has, and it looks like this:
The problem is that:
* The work of including and interpreting the include is done on the
server-side before downloading and adds a big overhead as the
server has to scan files for `include' statements.
* Consequently most servers (especially public ISP's) deactivate
this feature.
* `include' is all you get - no macro substitution, no parameters to
macros, no ifdef, etc, etc.
There are several other features of m4 that I have not yet exploited
in my HTML ramblings so far, such as regular expressions and doubtless
many others. It might be interesting to create a "standard" stdlib.m4
for general use with nice macros for general text processing and HTML
functions. By all means download my version of stdlib.m4 as a base for
your own hacking. I would be interested in hearing of useful macros
and if there is enough interest, maybe a Mini-HOWTO could evolve from
this paper.
There are many additional advantages in using Linux to develop HTML
pages, far beyond the simple assistance given by the typical Typing
Aids and WYSIWYG tools.
Certainly, this little hacker will go on using m4 until HTML catches
up - I will then do my last make and drop back to using pure HTML.
I hope you enjoy these little tricks and encourage you to contribute
your own. Happy hacking!
6. Files to download
You can get the HTML and the m4 source code for this article here (for
the sake of completeness, they're copylefted under GPL 2):
using_m4.html :this file
using_m4.m4 :m4 source
stdlib.m4 :Include file
makefile
Contents
_________________________________________________________________
Copyright © 1997, Bob Hepple
Published in Issue 22 of the Linux Gazette, October 1997
_________________________________________________________________
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
_________________________________________________________________
"Linux Gazette...making Linux just a little more fun!"
_________________________________________________________________
An introduction to The Connecticut Free Unix Group
by Lou Rinaldi lou@cfug.org, CFUG Co-Founder
_________________________________________________________________
October of 1996 was when Nate Smith and I first began discussing the
creation of a local-area unix users' group here in Connecticut,
something we felt the area was desperately in need of. We bantered
around some initial ideas; some great, some not so great. Finally we
decided on creating a group whose focus was on the "free unix"
community. CFUG, The Connecticut Free Unix Group, was born in November
of 1996. Both of us had very busy schedules, so all of the time we
were going to invest in this project came directly from our
ever-decreasing periods of leisure activity. We agreed upon three
major goals for CFUG: The first was the wide distribution and
implementation of free, unix-like operating systems and software. The
second was educating the public about important developments in the
evolution of free operating systems. Finally, we strove to provide an
open, public forum for debate and discussion about issues related to
these topics. After writing to several major vendors and asking for
donations of their surplus stock and/or older software releases, the
packages began rolling in. (After all, we wanted to create some sort
of incentive for people to come to the first meeting)! We then got
started doing some heavy advertising on the newsgroups, in local
computer stores and also on local college campuses. Finally, after
securing an honored guest speaker for our first meeting, (Lar Kaufman,
co-author of the seminal reference book "Running Linux"), we were
ready to set a date. December 9th, 1996 marked the first official CFUG
gathering, which took place at a local public library. We've held
meetings on the second Monday of each month ever since, and are now
widely recognized as Connecticut's only organization dedicated to the
entire free unix community. We've since lost Nate Smith to the
lucrative wiles of Silicon Valley, but we continue to carry on with
our original goals. We have close relations with companies such as
Caldera Inc., InfoMagic Inc., and Red Hat Software, as well as such
non-commercial entities as The FreeBSD Project, Software In The Public
Interest (producers of Debian GNU/Linux), The OpenBSD Project and The
Free Software Foundation. We were also featured on the front page of
the Meriden Record-Journal, a major local newspaper, on May 26th of
this year. Our future plans include more guest speakers, as well as
trips to events of pertinence throughout New England.
For more information, please check our website - http://www.cfug.org
There is a one-way mailing list for announcements concerning CFUG. You
can sign up by emailing cfug-announce-request@cfug.org with
"subscribe" as the first line of the message body (without the
quotes).
_________________________________________________________________
Copyright © 1997, Lou Rinaldi
Published in Issue 22 of the Linux Gazette, October 1997
_________________________________________________________________
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
_________________________________________________________________
"Linux Gazette...making Linux just a little more fun!"
_________________________________________________________________
Review: The Unix-Hater's Handbook
by Andrew Kuchling amk@magnet.com
_________________________________________________________________
I've written a review of an old (1994-vintage) book that may be of
interest to Linuxers. While even just its title will annoy people,
there actually is material of interest in the book to Linux developers
and proponents.
Andrew Kuchling
amk@magnet.com
http://starship.skyport.net/crew/amk/
_________________________________________________________________
The UNIX-HATERS Handbook (1994)
by Simson Garfinkel, Daniel Weise, and Steven Strassman.
Foreword by Donald Norman
Anti-Forward by Dennis Ritchie.
Summary: A sometimes enraging book for a Linux fan, but there are
valuable insights lurking here.
In his Anti-Forward to this book, Dennis Ritchie writes "You claim to
seek progress, but you succeed mainly in whining." That's a pretty
accurate assessment of this book; it's one long complaint about work
lost due to crashes, time wasted finding workarounds for bugs, unclear
documentation, and obscure command-line arguments. Similar books could
be written about any operating system. Obviously, I don't really agree
with this book; I wouldn't be using Linux if I did. However, there is
informative material here for people interested in Linux development,
so it's worth some attention.
The book describes problems and annoyances with Unix; since it was
inspired by a famous mailing list called UNIX-HATERS, there are lots
of real-life horror stores, some hilarious and some wrenching. The
shortcomings described here obviously exist, but in quite a few cases
the problem has been fixed, or rendered irrelevant, by further
development. Two examples:
* On the Unix file system: "...since most disk drives can transfer up
to 64K bytes in a single burst, advanced file systems store files in
contiguous blocks so they can be read and written in a single
operation ... All of these features have been built and fielded in
commercially offered operating systems. Unix offers none of them." But
the ext2 file system, used on most Linux systems, does do this;
there's nothing preventing the implementation of better filesystems.
* "Unix offers no built-in system for automatically encrypting files
stored on the hard disk." (Do you know of any operating system that
has such capability out of the box? Can you imagine the complaints
from users who forget their passwords?) Anyway, software has been
written to do this, either as an encrypting NFS server (CFS) or as a
kernel module (the loopback device).
There are some conclusions that I draw from reading this book:
First, when the book was written in 1994, the free Unixes weren't very
well known, so the systems described are mostly commercial ones.
Proponents of free software should notice how many of the problems
stem from the proprietary nature of most Unix variants at the time of
writing. The authors point out various bugs and missing features in
shells and utilities, flaws which could be *fixed* if the source code
was available.
Better solutions sometimes didn't become popular, because they were
owned by companies with no interest in sharing the code. For example,
the book praises journalled file systems such as the Veritas file
system, because they provide faster operation, and are less likely to
lose data when the computer crashes. The authors write, "Will
journaling become prevalent in the Unix world at large? Probably not.
After all, it's nonstandard." More importantly, I think, the file
system was proprietary software, and companies tend to either keep the
code secret (to preserve their competitive advantage), or charge large
fees to license the code (to improve their balance sheets).
The chapter on the X Window System is devastating and accurate; X
really is an overcomplicated system, and its division between client
and server isn't always optimal. An interesting solution is suggested;
let programs extend the graphics server by sending it code. This
approach was used by Sun's NeWS system, which used PostScript as the
language. Unfortunately NeWS is now quite dead; it was a proprietary
system, after all, and was killed off by X, which was freely available
from MIT. (Trivia: NeWS was designed by James Gosling, who is now
well-known for designing Java. Sun seems determined not to make the
same mistake with Java... we hope.)
Second, many of the problems can be fixed by integrating better tools
into the system. The Unix 'find' command has various problems which
are described in chapter 8 of the book, and are pretty accurate,
though they seem to have been fixed in GNU find. Someone has also
written GNU locate, an easier way to find files. It runs a script
nightly to build a database of filenames, and the 'locate' command
searches through that database for matching files. You could make this
database more than just a list of filenames; add the file's size and
creation time, and you can do searches on those fields. One could
envision a daemon which kept the database instantly up to date with
kernel assistance. The source is available, so the idea only needs an
author to implement it...
Chapter 8 also points out that shell programming is complex and
limited; shell scripts depend on subprograms like 'ls' which differ
from system to system, making portability a problem, and the quoting
rules are elaborate and difficult to apply recursively. This is true,
and is probably why few really sizable shell scripts are written
today; instead, people use scripting language like Perl or Python,
which are more powerful and easier to use.
Most important for Linux partisans, though, it's very important to
note that not all of the flaws described have been fixed in Linux yet!
For example, most Linux distributions don't really allow you to
undelete files, though the Midnight Commander program apparently
supports undeletes. As the authors say, 'sendmail' really is very
buggy, and Unix's security model isn't very powerful. But people are
working on new programs that do sendmail's job, and they're coding
security features like the immutable attributes, and debating new
security schemes.
For this reason, the book is very valuable as a pointer to things
which still need fixing. I'd encourage Linux developers, or people
looking for a Linux project, to read this book. Your blood pressure
might soar as you read it, but look carefully at each complaint and
ask "Is this complaint really a problem? If yes, how could it be
fixed, and the system improved? Could I implement that improvement?"
_________________________________________________________________
Copyright © 1997, Andrew Kuchling
Published in Issue 22 of the Linux Gazette, October 1997
_________________________________________________________________
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next
_________________________________________________________________
Linux Gazette Back Page
Copyright © 1997 Specialized Systems Consultants, Inc.
For information regarding copying and distribution of this material see the
Copying License.
_________________________________________________________________
Contents:
* About This Month's Authors
* Not Linux
_________________________________________________________________
About This Month's Authors
_________________________________________________________________
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.
Jim Dennis
Jim Dennis is the proprietor of Starshine Technical Services. His
professional experience includes work in the technical support,
quality assurance, and information services (MIS) departments of
software companies like Quarterdeck, Symantec/ Peter Norton Group, and
McAfee Associates -- as well as positions (field service rep) with
smaller VAR's. He's been using Linux since version 0.99p10 and is an
active participant on an ever-changing list of mailing lists and
newsgroups. He's just started collaborating on the 2nd Edition for a
book on Unix systems administration. Jim is an avid science fiction
fan -- and was married at the World Science Fiction Convention in
Anaheim.
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.
Bob Hepple
Bob Hepple has been hacking at Unix since 1981 under a variety of
excuses and has somehow been paid for it at least some of the time.
It's allowed him to pursue another interest - living in warm, exotic
countries including Hong Kong, Australia, Qatar, Saudi Arabia, Lesotho
and (presently) Singapore. His initial aversion to the cold was
learned in the UK. Ambition - to stop working for the credit card
company and taxman and to get a real job - doing this, of course!
_________________________________________________________________
Not Linux
_________________________________________________________________
Thanks to everyone who contributed to this month's issue!
I'm very excited to edit the Linux Gazette for October.
At my last job, where I fixed computers for a big company, I was
talking with a woman about life in general while fixing her computer,
and suddenly she blurted: "Oh my God! You're really a computer geek!"
She immediately apologized and explained that she didn't mean any
offense, even though I had a huge smile on my face and was trying to
explain that I appreciated the compliment.
After many experiences like that, working with SSC has been a welcome
change. And since Linux Gazette is one of the places where geeks come
home to roost, I'm happy to be a part of it.
I just came back from the Grace Hopper Celebration for Women in
Computing, which was held in San Jose, California this year. To quote
Bill and Ted, it was totally awesome! I got to meet the illustrious
Anita Borg, the amazing Ruzena Bajcny, and the inspiring Fran Allen
from IBM, as well as many many many others who came from all over the
country, and from dozens of countries from around the world. It was
the most incredible even that I have ever attended, and I encourage
everyone to go to the next one which will be in the year 2000.
Margie Richardson will return next month as Editor-In-Chief, and I'll
be helping out on the sidelines. I'm really glad that I got the chance
to be the Big Cheese for a month. :)
Keep sending those articles to gazette@ssc.com!
Until next month, keep reading and keep hacking!
_________________________________________________________________
Viktorie Navratilova
Editor, Linux Gazette gazette@ssc.com
_________________________________________________________________
[ TABLE OF CONTENTS ] [ FRONT PAGE ] Back
_________________________________________________________________
Linux Gazette Issue 22, October 1997, http://www.ssc.com/lg/
This page written and maintained by the Editor of Linux Gazette,
gazette@ssc.com
$1
m4_ifelse($#,1,,`_Table_Hdr_Item(m4_shift($@))')')
m4_define(`_Table_Row_Item', `$1
m4_ifelse($#,1,,`_Table_Row_Item(m4_shift($@))')')
m4_define(`_Table_Hdr',`_Table_Hdr_Item($@) ')
m4_define(`_Table_Row',`_Table_Row_Item($@) ')
m4_define(`_End_Table',