Writing HTML with m4
In many “nests” of HTML pages, each page shares elements such as a button bar containing links to other pages like this:
[Home] [Next] [Prev] [Index]
This is fairly easy to create in each page. The trouble is that if you make a change in the “standard” button-bar then you have the tedious job of finding each occurrence of it in every file and manually making the changes. With m4 we can more easily do this job by putting the shared elements into an m4_include statement, just like C.
Let's also automate the naming of pages by putting the following lines into an include file called button_bar.m4:
m4_define(`_BUTTON_BAR', <a href="homepage.html">[Home]</a> <a href="$1">[Next]</a> <a href="$2">[Prev]</a> <a href="indexpage.html">[Index]</a>)
and then these lines in the document:
m4_include button_bar.m4 _BUTTON_BAR(`page_after_this.html', `page_before_this.html')The $1 and $2 parameters in the macro definition are replaced by the strings in the macro call.
It is troublesome to have items change in multiple HTML pages. For example, if your e-mail address changes, you need to change all references to it to the new address. Instead, with m4 you can put a line like the following in your stdlib.m4 file:
and then just put _EMAIL_ADDRESS in your m4 files.
A more substantial example comes from building strings with multiple components, any of which may change as the page is developed. If, like me, you develop on one machine, test out the page and then upload to another machine with a totally different address, then you could use the m4_ifdef command in your stdlib.m4 file (just like the #ifdef command in cpp). For example:
m4_define(`_LOCAL') ... m4_define(`_HOMEPAGE', m4_ifdef(`_LOCAL', `//127.0.0.1/~YourAccount', `http://ISP.com/~YourAccount')) m4_define(`_PLUG', `<A HREF="http://www.ssc.com/linux/"> <IMG SRC="_HOMEPAGE/gif/powered.gif" ALT=<"[Linux Information]"> </A>')
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 definition can then ripple through the entire project as you build the pages.
In this example, _PLUG is a macro to advertise Linux. When you are testing your pages, use the local version of _HOMEPAGE. When you are ready to upload, remove or comment out the _LOCAL definition in this way:
... and then re-make.
Styles built into HTML include things like <EM> for emphasis and <CITE> for citations. With m4 you can define your own new styles like this:
If, later, you decide you prefer <STRONG> instead of <EM>, it is a simple matter to change the definition. 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 <EM>...</EM> rather than the physical styles such as <I>...</I> in your documents.” Curiously, the WYSIWYG editors for HTML generate purely physical styles. Using the m4 styles may be a good way to keep on using logical styles.
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:
<BLOCKQUOTE><PRE><CODE>Some code you want to display. </CODE></PRE></BLOCKQUOTE>
_CODE(Some code you want to display.)In this case, you would define _CODE like this:
m4_define(`_CODE', <BLOCKQUOTE><PRE><CODE>$1</CODE></PRE></BLOCKQUOTE>)Which version you prefer is a matter of taste and convenience although the m4 macro certainly saves some typing. Another example I like to use, since I can never remember the syntax for links, is:
m4_define(`_LINK', <a href="$1">$2</a>)Then, instead of typing:
<a href="URL_TO_SOMEWHERE">Click here to get to SOMEWHERE </a>I type:
_LINK(`URL_TO_SOMEWHERE', `Click here to get to SOMEWHERE')
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide