File: wkndmech.html

package info (click to toggle)
lg-issue18 3-1
  • links: PTS
  • area: main
  • in suites: slink
  • size: 2,924 kB
  • ctags: 146
  • sloc: makefile: 30; sh: 3
file content (1284 lines) | stat: -rw-r--r-- 48,094 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
<!--startcut =======================================================  -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Draft//EN">
<HTML>
<HEAD><TITLE>Linux Weekend Mechanic - June 1997</TITLE></HEAD>

<BODY BGCOLOR=#FFFFFF>
<!--endcut =========================================================  -->

<H4>
&quot;Linux Gazette...<I>making Linux just a little more fun!</I>&quot;
</H4>
<P><HR><P>
<!--================================================================ -->

<CENTER>
<IMG SRC="../gx/fisk/wkndMech.gif" ALIGN=BOTTOM WIDTH=397 HEIGHT=150>
<H1>Welcome to The Linux Weekend Mechanic!</H1>
<H2>Published in the June 1997 Edition of the Linux Gazette</H2>
<FONT SIZE="2"><B>
Copyright (c) 1997 John M. Fisk &lt;fiskjm@ctrvax.vanderbilt.edu&gt;<BR>
The Linux Gazette is Copyright(c) 1997 <A HREF="http://www.ssc.com/">
Specialized Systems Consultants Inc.</A>
</B></FONT>
</CENTER>

<P><HR>

<H2>Time To Become... <I>The Linux Weekend Mechanic!</I></H2>
<TABLE>
<TR>
    <TD ALIGN=TOP>
    <IMG SRC="../gx/fisk/mechanic.gif" ALIGN=BOTTOM WIDTH=147 HEIGHT=66>

    <TD ALIGN=LEFT VALIGN=TOP>
    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!
</TABLE>

<P><HR><P>

<!-- TABLE OF CONTENTS ================================================ -->
<H2>Table of Contents</H2>

<UL>
    <LI><A HREF="#welcome">Welcome to the June 1997 Weekend Mechanic!</A>
    <LI><A HREF="#wallpapering">Wallpapering with XV:  A Followup</A>
    <LI><A HREF="#vim-perks">VIM Programming Perks</A>
    <LI><A HREF="#closing">Closing Up The Shop</A>
</UL>
<!-- END TABLE OF CONTENTS ============================================ -->

<P><HR><P>

<!-- WELCOME SECTION ================================================== -->
<H2><A NAME="welcome"><IMG SRC="../gx/fisk/attndant.gif" WIDTH=129 HEIGHT=99>
Welcome to the June 1997 Weekend Mechanic!</A></H2>

<P>
Hey, c'mon in!

<P>
Thanks for dropping by!  How y'all been doing?

<P>
So... everyone survive the semester?!  I just finished taking my last final a
day or so ago AND managed to find work (with the folks in Biomedical
Informatics at Vanderbilt Univ. Medical Center :-) within 24 hours of
finishing up.  PHEW!!  Nice to be done.

<P>
Anyway, I'm going to apologize for the potentially &quot;dry&quot; topics in
this month's WM.  I've not been doing much besides programming, cramming, and
making occasional trips to the 'fridge, restroom, and bedroom (pretty much in
that order...).  I ended up doing a fair amount of programming for a couple
classes and got VERY acquainted with a number of the programming tools available
under Linux -- VIM, ctags, xxgdb, ddd, and so forth.  Since this is what I've
been doing of late, I thought that this might be an appropriate topic.  The
proviso is that you understand that you take this strictly as a novice's
introduction to a couple of these tools.

<P>
How's <I>that</I> for being wishywashy... :-)

<P>
Anyway, I've found a few useful things along the way and thought someone might
enjoy my sharing them.

<P>
Also, I want to continue to thank all of you who've taken the time to write
and offer comments and suggestions.  Believe me, I don't claim extensive
knowledge or expertise in most of the things I write about -- these are mostly
discoveries and ideas that I've hit upon and am sharing in the hopes that they
might be helpful.  I welcome corrections, clarifications, suggestions, and
enhancements!  Several of you wrote in with regards to <B>wallpapering using
XV</B> which I'll be sharing below.

<P>
Well, thanks again for stopping by!  Hope you enjoy :-)

<P>
John M. Fisk<BR>
Nashville, TN<BR>
Thursday, 8 May 1997

<!-- END WELCOME SECTION ============================================== -->

<P><HR><P>

<!--  ARTICLE ====================================================== -->
<H2><A NAME="wallpapering"><IMG SRC="../gx/fisk/desklamp.gif" WIDTH=79 HEIGHT=99
ALIGN=BOTTOM></A>Wallpapering with XV:  A Followup</H2>

<P>
My sincerest thanks to <B>Brent Olson, Peter Haas, and Bill Lash</B> for
taking the time to write and offer these suggestions.  I tried tinkering
around with a few of these suggestions and they work like a champ!  Here they
are:

<BLOCKQUOTE>

<P><HR><P>

Date: Wed, 02 Apr 1997 09:24:59 -0800<BR>
From: Brent Olson &lt;brent@primus.com&gt;<BR>
To: fiskjm@ctrvax.Vanderbilt.Edu<BR>
Subject: re:  reducing the colors in a background<BR>

<P>
You've probably already been told this, but in the LG article relating
to reducing the number of colours used in the background, there is no
need to convert the picture first.  It can be done on the fly:

<PRE>
xv -root -quit -maxpect -ncols 16 filename.gif
</PRE>

<P>
Works great on my lousy 8-bit NCD display at work.

<P>
Brent Olson<BR>
mailto:  brent@primus.com

<P><HR><P>

Date: Tue, 08 Apr 1997 08:42:01 +0200 (MET DST)<BR>
From: hap@adv.magwien.gv.at<BR>
To: fiskjm@ctrvax.Vanderbilt.Edu<BR>
Subject: xv - interesting options<BR>

<P>
There are another two interesting options of xv:

<PRE>
-random filepattern   selects a random picture of given given filepattern 
-ncols #colors        to limit number of used colors
</PRE>

<P>
An example out of my .fvwm2rc95:

<PRE>
xv -quit -root -ncols 16 -random /var/X11R6/lib/xinit/pics/*.gif
</PRE>

<P>
Regards, Peter
<PRE>
-- 
 (~._.~)    From the keyboard of Peter Haas (hap@adv.magwien.gv.at)
 _( Y )_    Located at MA14-ADV, Rathausstr.1, A-1082 Wien, Austria
()_~*~_()   Phone +43-1-4000/91126   FAX +43-1-4000/7141
 (_)-(_)    &quot;Big iron&quot; division
</PRE>

<P><HR><P>

From lash@tellabs.com Thu Apr 24 21:20:39 1997<BR>
Date: Thu, 24 Apr 1997 17:52:27 -0500<BR>
From: Bill Lash &lt;lash@tellabs.com&gt;<BR>
To: fiskjm@ctrvax.Vanderbilt.Edu<BR>
Subject: Limiting colors with XV<BR>

<P>
John,

<P>
I read your article on wallpapering with XV.  You suggest choosing
images with a limited number of colors.  You go on to suggest several
options, but you missed a simple solution.  You can tell XV how
many colors to use in displaying the picture using the -ncols option.

<P>
At work, I usually run with a background of 100 colors on an 8-bit
pseudocolor display with the following command line:

<PRE>
xv -root -quit -max -rmode 5 -ncols 100 image.gif
</PRE>

<P>
Bill Lash<BR>
lash@tellabs.com
</BLOCKQUOTE>

<P><HR><P>

<P>
Again, guys, thanks for writing.  Happy wallpapering!

<P>
John

<!-- END ARTICLE ================================================== -->

<P><HR><P>

<!--  ARTICLE ====================================================== -->
<H2><A NAME="vim-perks"><IMG SRC="../gx/fisk/desklamp.gif" WIDTH=79 HEIGHT=99
ALIGN=BOTTOM>VIM Programming Perks</A></H2>

<P>
Well, as I mentioned above, I ended up spending a good deal of time
programming this semester.  Our software engineering team designed and coded a
simple FORTRAN 77 spell checker in C++.  Thing was, the analysis and design
phase consumed 11 of the 14 weeks of the semester AND it was done using
Structured Analysis.  Problem was, we had decided to code this thing in C++
and so ended up almost completely redesigning it using OO Analysis and Design 
during the last couple weeks (when we were <I>supposed</I> to be doing nothing
but coding :-).

<P>
Anyway, this meant a LOT of late nights -- integrating everyone's code got a
bit hairy, since none of us had much experience with team coding.  I was
mighty thankful for the development tools under Linux.  I spent the better
part of 13 hours one Saturday debugging our first effort at integrating the
code -- chasing down Segmentation Faults and infinite loops :-)

<P>
Ahhh... the stuff of programming... :-)

<P>
Along the way I learned a few interesting and nifty things about the VIM
editor, which has been my 'ol workhorse editor for the past couple years now.
I wanted to give this thing another plug as I think it's one of the best
things since sliced bread.  I'll admit that the <B>emacsen</B>, including the
venerable <B>XEmacs</B>, are a LOT more powerful and full featured.  But,
having developed the finger memory for the &quot;one-key-vi-commands&quot;
I've found that I can get a lot of work done fast.  I'd like to 'tip the hat
at this point to <B>Jesper Pedersen and Larry Ayers</B> both of whom have
written very nice articles on emacs and XEmacs in past issues of the LG and
the Linux Journal.  I'd encourage anyone interested in these to have a look at
these articles.  I'll also be mentioning XEmacs below and give you a screen
shot of the latest 19.15 iteration.

<P>
Anyway, here's a few (hopefully) interesting notes and ideas for using the VIM
editor!  

<H3>GVIM -- Going Graphical!</H3>

Yup, that's right!  VIM has gone GUI :-)

<P>
I recently downloaded and compiled the latest beta version of VIM which is
version 5.0e.  If you have the Motif development libraries you can compile VIM
with a Motif interface -- gvim.  This rascal is pretty good sized and not
exactly fleet of foot.  It's a bit slow getting out of the gate on startup and
so it's probably prudent to heed the Makefile suggestions and compile separate
versions of VIM both with and without X support.  I tried starting versions of
vim (at the console) compiled with and without X support and the extra X
baggage definitely slows things down.

<P>
A bit later on in this article I've provided several screen dumps of gvim as
well as a couple other editors and the xxgdb and ddd debuggers.  If you're the
impatient or curious type, please feel free to jump ahead and have a look.
Also, I've included a couple links for additional information.

<P>
Actually, VIM has provided a GUI since around version 4.0.  I've been using
this for some time now and find that it adds a several enhancements over vim
at the console:

<UL>
    <LI>it has a reasonably handsome and functional scrollbar
    <LI>mouse support is automatic and allows VERY easy cursor movement, text
    highlighting, and cut-and-paste operations
    <LI>it provides a customizable menubar
    <LI>it intelligently understands the movement keys -- Home, End, Page Up,
    Page Down, arrow keys -- <I>even</I> in insert mode
    <LI>depending on how you have your .Xmodmap set up, it will intelligently
    handle Back Space, and Delete keys AND you can delete backwards over
    multiple lines!
</UL>

This last point is wonderful.  Anyone who's ever tried to backspace onto the
end of a previous line and gotten that miserable BEEP! will appreciate this.
What's particularly nice about the graphical version of vim is that it
provides several basic features of a GUI style editor while retaining the
speed and flexibility of vi.

<H3>The <I>Big</I> News:  Syntax Highlighting!</H3>

This is truly a godsend and was one of the features that was definitely on the
'ol wish list!  VIM now provides color syntax (lexical) highlighting for a
variety of languages including C, C++, HTML (which I'm using right now...),
Java, Ada95, FORTRAN, Perl, and TeX.  But that's not all...!

<P>
(...this is like the guy hawking the $2.99 Ginzu knives, &quot;<I>they slice,
they dice, here... I can cut through a cinder block wall, this lamp post, a
street sign, AND the hood of this guy's car and never loose an edge!  But 
that's not all... if you act right now...</I>&quot;)

<P>
You get the point.

<P>
What I was going to say was that vim also provides syntax highlighting for
shell scripts (VERY COOL!), makefiles, and the VIM help files (which you'll
see here in just a bit).  All in all, this is pretty nice.  I've been
tinkering around with this a bit and am really starting to like it.  Be aware
that the highlighting isn't quite as &quot;intelligent&quot; as with something
like XEmacs -- it doesn't provide the same degree of sophistication.  Still,
it's very good and, being an order of magnitude smaller and a good deal more
nimble, it's well worth trying.

<P>
VIM installed the support files for syntax highlighting (at least on my
system) under /usr/local/share/vim/syntax.  There are individual files for the
various languages and file types as well as the syntax.vim file that does a
lot of the basic coordination.  You can tinker around with these to get the
&quot;look-n-feel&quot; that you want.  Keep in mind that to get automatic
syntax highlighting you'll need to add something like this to your ~/.vimrc or
~/.gvimrc file:

<PRE>
&quot; Enable automatic color syntax highlighting on startup
source /usr/local/share/vim/syntax/syntax.vim
</PRE>

<P>
I have to admit that I wrestled with this for longer than I should have trying
to figure out how this was done.  Hopefully, this will save you some trouble
:-)

<P>
Again, I've included screen dumps below so that you can see what this looks
like.  In addition, the VIM home page has a couple nice screen shots that you might
want to have a look at.  I should add that syntax highlighting is
individually configurable for the console and the X version.  Now, before you
go dashing off and &quot;<I>rushing in where angels fear to tread...</I>&quot;
you will probably want to have a look at the help files or documentation -- it
gives some basic guidelines for customizing this stuff.

<P>
And speaking of which...

<H3>Help is on the way!</H3>

One of the coolest and most useful things about VIM is the mind numbing amount
of documentation that comes with it.  There's a small library of support
documents covering everything from a blow-by-blow description of <I>each</I>
feature and command to information about showing thanks by providing help for
a needy Uganda.

<P>
And what's more, all of this is provided on-line.  In command mode you simply
type in:

<PRE>
:help
</PRE>

and the window (under gvim) splits and loads up the top level help file.  This
is your gateway to knowledge.

<P>
&quot;<I>...use the Source, Luke</I>&quot;

<P>
The help system is set up in a hypertext fashion.  If you've enabled automatic
syntax highlighting then even the help system is colorized.  To follow a link
you can either hit the letter &quot;g&quot; and then single click with the
mouse on a topic, or you can move the cursor to that topic and hit
&quot;Ctrl-]&quot; (hold down the control key and hit the left square bracket
key -- &quot;]&quot;).  To get back up to where you started, hit
&quot;Ctrl-t&quot;.

<P>
It's that simple :-)

<P>
IMHO, this is one of the most laudable features of VIM.  The documentation is
generally well written and reasonable understandable.  It is VERY thorough
and, since it's available from within the editor, provides a high level of
usability.  It also provides a &quot;Tips&quot; section as well as numerous
&quot;How Do I...?&quot; sections.  It's Must Reading...

<H3>Ask &quot;<I>The Man!</I>&quot;</H3>

Another really useful thing to try is accessing manual pages from within vim.
Say you were writing a shell script and needed to quickly look up something in
the bash manual page or you were setting up a test condition and couldn't
remember the syntax for the &quot;greater than&quot; test, all you have to do
is:

<PRE>
:!man test
</PRE>

and <I>presto!</I>, information.  It's instant gratification at its
best... :-)

<P>
To be honest, I've found that this works a LOT better at the console than
under gvim, although the exact reason eludes me.  Under gvim, I get the
following error:

<PRE>
WARNING! Terminal is not fully functional
</PRE>

got me on this one...

<P>
My suspicion is that it has to do with the termcap stuff built into the
editor.  Forward movement down the manual page (hitting the space bar) is
reasonable smooth, but backward movement is very jerky and screen redraws are
incomplete.  Still, if you can live with that you'll find this VERY
convenient.

<H3>TAG, You're It!</H3>

This is another one of those things that makes life SO much easier.  If you've
not used tags before then brother, it's time to start!

<P>
Basically what tags allow you to do is find that point at which a function or
variable is declared.  For example, suppose you ran across the following
snippet of code:

<PRE>
    HashTable HTbl;
    HTbl.Load(&quot;hash.dat&quot;);
    found = HTbl.Lookup(buf);
    .
    .
    .
</PRE>

and were interested in finding out how the Load method was implemented.  To
jump to the point in the file where this is defined simply move the cursor so
that it sits on &quot;Load&quot;:

<PRE>
    HTbl.Load(&quot;hash.dat&quot;);
         ^
</PRE>

and hit &quot;Ctrl-]&quot; (hold down the control key and hit the right square
bracket key -- &quot;]&quot;).  Beauty of this is, that even if the definition
is not in the file you're currently working on, vim will load up the needed
file and position the cursor at the first line of the function definition.

<P>
This is seriously cool!

<P>
When you're ready to move back to your original location, hit
&quot;Ctrl-t&quot; (which moves you back up the tag stack).  I've been using
<B>Exuberant Ctags, version 1.5, by Darren Hiebert</B> for the past little bit
now and really like this a lot.  As the name implies, it does a pretty
thorough job of scouring your source files for all sorts of useful stuff --
function declarations, typedefs, enum's, variable declarations, macro
definitions, enum/struct/union tags, external function prototypes, and so
forth.  It continues on in the time honored tradition of providing a bazillion
options, but not to fear:  it's default behavior is sane and savvy and
provides a very nice OOBE*.

<P>
<I>*(Out Of Box Experience)</I>

<P>
You should be able to find Darren's Exuberant Ctags (ctags-1.5.tar.gz was the
most recent version on sunsite and its mirrors at the time of writing) at any
sunsite mirror.  I happened across it in the Incoming directory.  You'll
probably find is somewhere under the /devel subdirectory now.  If you get
stuck and really can't find it, drop me a note and I'll see what I can do to
help.  This one is definitely worth having.

<P>
Oh, BTW, using ctags is child's play:  simple give it the list of files that
you want it to search through and it'll create a &quot;tags&quot; file in your
current directory.  Usually, this is something like:

<PRE>
ctags *.cc *.h
</PRE>

if you happen to be doing C++ programming, or:

<PRE>
ctags *.c *.h
</PRE>

if you're programming in C.  That's all there is to it!  Keep in mind that you
can use tags without having to position the cursor on top of some function or
variable.  If you'd defined a macro isAlpha and wanted to jump to your
definition, then simply type in:

<PRE>
:ta isAlpha
</PRE>

and vim will take you to that point.  How 'bout that for easy?  There's a good
deal more info on using tags in the VIM online documentation.  Browse and
enjoy!

<H3>Using the <I>Real</I> Windows...</H3>

Another very handy item that gvim (and vim) provides is multiple windows.
This makes cutting and pasting from one file to another (or from one section
of a file to another) quite easy.  It also is nice if you're reading one file
and editing another (for example, reading an INSTALL file while making changes
to the Makefile).

<P>
To pop up a second (or third, or fourth...) window with a specific file,
simply use something like:

<PRE>
:split ctags.README
</PRE>

This would create a second window and load up the ctags.README file.  If you
want a second window with the current file displayed there, then simply use:

<PRE>
:split
</PRE>

and a second window will be created and the current file loaded into that
window.  Under gvim, moving the cursor from one window to the other is as
simple as mouse clicking in the desired window.  You can also use the
keystrokes

<PRE>
Ctrl-w j (hold down control and hit &quot;w&quot;, then hit j)
Ctrl-w k (hold down control and hit &quot;w&quot;, then hit k)
</PRE>

to move to the window <B>below</B> or the window <B>above</B> the current
window respectively.  But, use the mouse... it's a lot easier :-)

<P>
Resizing the windows is nicely handled using the mouse:  simply click
anywhere on the dividing bar between the two windows and drag the bar to
whatever size you want.  This is really handy if you are using one file as an
occasional reference but want to edit in a full window.  You can resize the
reference file down to a single line when it's not needed.

<P>
Again, there's a lot more information in the online help about using multiple
windows.

<H3><I>SHHHHHhhhh.....!</I> Let Me Tell You A Secret!</H3>

Here's a little something that ought to part of one of those blood oath,
&quot;cross-my-heart-and-hope-to-die&quot;, secret society initiations into
the &quot;Secret Lodge of Some Large North American Mammal Society&quot;

<P>
Ready...? (look furtively around with squinty, shifty gaze...)

<P>
(... the clock ticks loudly in the other room, somewhere in the distance a dog
barks, the room falls into a stifling hush...)

<P>
He clears his throat loudly and in a harsh whisper exclaims...

<P>
&quot;The &quot;%&quot; sign expands to the current buffer's filename!&quot;

<P>
Phew!  Glad that's over... :-)

<P>
Yup, with this little tidbit you can do all sorts of cool and groovy things.
Like what you ask...?  (you knew this was coming, didn't you... :-)

<DL>
    <DT><B>RCS checkin and checkout</B><P>
    <DD>I won't go into using RCS for version control except to say that doing
    checkin's and checkout's from within VIM is VERY easily accomplished doing
    something like:

    <PRE>
    :w!
    :!ci -l %
    :e %
    </PRE>

    <P>
    So what's going on...?  Well, the first line writes the current buffer to
    file, the real good stuff happens on the second line in which you use the
    RCS <B>ci</B> to checkin and lock the current file.  And finally, since
    the checkin process may have altered the file if you've included
	&quot;Header&quot;, &quot;Id&quot;, &quot;Log&quot;, etc.,
    reloads the file with the new RCS information (if any).

    <P>
    Now, for all you VIM jockeys out there, the handy thing to do is use
    &quot;map&quot; to bind this sequence to a single keystroke.  I've bound
    this to Alt-r and it makes the whole operation smooth and painless.
    <P>

    <DT><B>Printing that 'ol file</B><P>
    <DD>This is another favorite trick.  To print the current file from within
    vim simply:

    <PRE>
    :w!
    :!lpr %
    </PRE>

    what could be easier? :-)

    <P>
    Seriously, this is a very convenient means of getting a hard copy of your
    current file.  The one caveat to remember is that you'll probably want to
    commit the contents of your current editing buffer to file <I>before</I>
    you try to print it.

    <P>
    I've been using the <B>apsfilter</B> program for last year or so and
    absolutely love it.  It is a series of shell scripts that automate the
    process of printing.  Basically, it uses the <B>file</B> command to
    determine the type of file to print and then invokes lpr with the
    appropriate print filter.  As a backend, it uses the <B>a2ps</B> program
    to format ASCII into Postscript and then uses Ghostscript to do the actual
    printing.  Now, using something like:

    <PRE>
    lpr [filename]
    </PRE>

    transparently formats the file to Postscript and sends it to the printer.
    I've been quite pleased with this.  You should be able to find this and
    similar programs at any of the sunsite FTP sites under the
    /pub/Linux/system/print (printer?, printing?) subdirectory (sorry, I'm not
    connected to the 'net at the moment and can't recall the exact
    subdirectory name off the top of my head :-).

    <P>
    Also, I've played with the a2ps program itself and found all sorts of cool
    and nifty options -- single page/double page printing, headers, boundary
    boxes, setting font sizes, and so forth.  I particularly like being able
    to set the font size and header information.  And, as always, IHABO*.

    <P>
    *(<I>It Has A Bazillion Options</I>)
    <P>

    <DT><B>Word Counts...</B><P>
    <DD>If you hit the Ctrl-g key combo, VIM prints the filename, number of
    line, and the current position in the file on the bottom status line.
    However, if you want a word or byte count, simply invoke the <B>wc</B>
    program on the file:

    <PRE>
    :w!
    :!wc %
    </PRE>

    which will print out the file's line, word, and byte count.
    <P>
</DL>

<P>
You get the picture.  Basically, any command that takes the form

<PRE>
command [-options] filename
</PRE>

can be used from within VIM doing something like:

<PRE>
:! command [-options] filename
</PRE>

<P>
Note that there are a couple other handy little items you might be interested
in.  If you want to include the contents of a file in the current buffer, OR
if you want to capture the output of a command into the current buffer (for
example, a directory listing), then use:

<PRE>
:r a2ps.README
:r! ls /usr/local/lib/sound/*.au
</PRE>

<P>
The first command would insert the contents of the a2ps.README file in the
current buffer wherever the cursor was located; the second command would
insert the output of an <B>ls</B> listing for the /usr/local/lib/sound/
directory.  That is, you can use this second form for any command that
<I>prints its output to standard out</I>.

<P>
This discussion leads directly into the question of spell checking the
current buffer.  And the answer that <I>I've</I> got is that I haven't found
an easy or convenient way to do this.  I ran across a key mapping definition a
while ago that basically copied the current file to the /tmp directory, ran
ispell on this file, and then copied this file back over the original.  It
worked, but it was clunky.  I've also tried, with some modest success, to do
something like:

<PRE>
:w!
:! ispell %
:e %
</PRE>

which basically commits the current buffer to file, starts a shell and runs
ispell on the file, and then reloads that file once the spell checking is
done.  Thing is, this works at least reasonably well running vim in text mode;
under gvim, ispell gives an error message to the effect:

<PRE>
Screen too small:  need at least 10 lines
Can't deal with non-interactive use yet.

1 returned
</PRE>

<P>
Ideas anyone?

<H3>Running Make!</H3>

The specifics of setting up a makefile are, in academic parlance,
&quot;<I>beyond the scope of this article...</I>&quot;.  (You can, however,
find a good deal of information about makefiles using <B>info</B>; or, more
appropriately, <B>O'Reilly &amp; Assoc.</B> put out a very nice little book
on managing projects using make -- hit up you friendly neighborhood librarian
or find it at your favorite Linux bookstore!)

<P>
I've found that gvim, in particular, provides excellent support for make.
Basically, once you have a working makefile, simply invoke it using:

<PRE>
:make
</PRE>

As the build process proceeds, you'll see all sorts of nifty messages go
whizzing by.  If make terminates on an error, gvim will very kindly load up
the errant file and position the cursor at the line that was implicated as
being the culprit.  This is VERY handy.  Also, if multiple errors are
encountered, you can move from one error to the next using:

<PRE>
:cn
</PRE>

which advances to the next error.  For some reason, the console version of vim
hasn't worked quite a well as gvim.  It doesn't always automatically go to the
first error encountered, although using the &quot;:cn&quot; command seems to
work fine.

<H3>And So Forth...</H3>

<P>
Phew!  How's everyone doing...? Still hanging in there?  I'm almost done here
so stay tuned. :-)

<P>
There are LOTS of other rather nifty features that vim/gvim provides.  
The adventurous will find all sorts of goodies to experiment with in the
online documentation.  Let me call your attention to just a few more and we'll
wrap this up and have a look at some screen shots!

<P>
<B>Unlimited Undo</B>

<P>
The way vim is (generally) configured, it keeps track of ALL the editing
changes you've made to a file.  So, after an hour's worth of editing, should
you decide that <I>War And Peace</B> really didn't need a another chapter,
then you can back out of all your changes by repeatedly hitting the
&quot;u&quot; key.  This reverses the changes you've made to the file in a
sequential fashion.  Now for a major back out, you'd have done well to check
the original file in under RCS and then retrieve this version if you decide
not to keep your current changes.  Still, you can back all the way out if you
don't mind hitting &quot;u&quot; for a while... :-)

<P>
<B>Compressed File Support</B>

<P>
One of the other nice things introduced into vim around version 4.0 was
support for editing compressed files.  Essentially, what this involves is
transparent uncompressing of the file upon the start of editing and
recompressing the file when vim terminates.  This is quite helpful as it
allows you to save a LOT of space if you work with a large number of text
files that can be compressed.  You may also be aware of the fact that the
pager &quot;less&quot; has this support built in and so do most all of the
&quot;emacsen&quot;.

<P>
The support for this is configured in using an entry in your ~/.vimrc or
~/.gvimrc.  I use the stock vimrc example that comes with the distribution:

<PRE>
&quot; Enable editing of gzipped files
&quot;    read: set binary mode before reading the file
&quot;          uncompress text in buffer after reading
&quot;   write: compress file after writing
&quot;  append: uncompress file, append, compress file
autocmd BufReadPre,FileReadPre      *.gz set bin
autocmd BufReadPost,FileReadPost    *.gz '[,']!gunzip
autocmd BufReadPost,FileReadPost    *.gz set nobin

autocmd BufWritePost,FileWritePost  *.gz !mv &lt;afile&gt; &lt;afile&gt;r
autocmd BufWritePost,FileWritePost  *.gz !gzip &lt;afile&gt;r

autocmd FileAppendPre           *.gz !gunzip &lt;afile&gt;
autocmd FileAppendPre           *.gz !mv &lt;afile&gt;r &lt;afile&gt;
autocmd FileAppendPost          *.gz !mv &lt;afile&gt; &lt;afile&gt;r
autocmd FileAppendPost          *.gz !gzip &lt;afile&gt;r
</PRE>

<P>
I still haven't completely gotten the hang of the autocmd stuff -- I suspect
that there's all sorts of wild and fun things that you can do with this.
Ahhh... places to go and things to do...!

<P>
<B>Auto-Fill and Auto-Comment Continuation</B>

<P>
Here's yet <I>another</I> nifty little feature that makes life fuller and
richer... :-)

<P>
You can set a text width variable in your ~/.gvimrc file that will do
auto-fill (or auto-wrapping) at that line length.  Currently, I have this set
to 78 so that whenever the line exceeds 78 characters the line is
automagically continued on the next line.  This is a Very Nice Thing when
typing text, although it can be a bit of a nuisance (and can be shut off) when
programming.

<P>
However...

<P>
There's an additional benefit to using this auto-fill thingie... if you're
inserting a comment in C, C++, a shell script, whatever..., all you have to do
is start the first line with a comment character (&quot;/*&quot;,
&quot;//&quot;, &quot;#&quot;) and then start typing.  If the comment extends
to the text width column, it automatically continues this on the next line AND
adds the appropriate comment character!

<P>
Very Slick! :-)

<P>
<B>Choices, Choices...!</B>

<P>
Well, the recurrent theme of the day is &quot;choices!&quot;.  VIM comes with
more options than you can shake a stick at.  I'd encourage you to have a look
at the online docs for a description of these.  Not all of them will be useful
to you but there are a LOT of interesting things that you can configure.  My
own favorite ones include:

<PRE>
set ai                &quot; turn auto indenting on
set bs=2              &quot; allow backspacing over everything in insert mode
set noet              &quot; don't expand tabs into spaces
set nowrap            &quot; disable line wrapping
set ruler             &quot; display row,col ruler
set showmatch         &quot; show matching delimiter for parentheses, braces, etc
set ts=4              &quot; set tab stop width to 4
set tw=78             &quot; always limit the width of text to 78
set sw=4              &quot; set the shift width to 4 spaces
set viminfo='20,\&quot;50  &quot; read/write a .viminfo file, don't store more
                      &quot; than 50 lines of registers
</PRE>

<P>
One thing to call you attention to:  the shift width stuff is something that
you might not have tried yet or come across.  Suppose that you've coded some
horrendous switch statement and then realize that you need to add a while loop
before it.  You code in the while loop stuff and then go back and arduously
re-indent everything in between.

<P>
There's an easier way... :-)

<P>
Simply highlight the lines that you want to indent, either indent in or indent
back out, using the mouse or &quot;:v&quot; (for keyboard highlighting) and
then hit the &quot;&gt;&quot; key to indent the lines in farther or the
&quot;&lt;&quot; key to indent back out.  Now, the nice thing is that you can
set the amount of indentation using the &quot;sw&quot; (shiftwidth) variable.

<P>
Also, keep in mind that while you normally set options in the ~/.vimrc or
~/.gvimrc configuration files, there's nothing to prevent your changing these
options on the fly, and in different parts of your file.  It's pretty common
to turn off autoindentation when you're doing cutting and pasting.  To turn
autoindenting off, simply type in:

<PRE>
:set noai
</PRE>

and off it goes.  To turn it back on use &quot;:set ai&quot;.

<P>
Two other options that I particularly like are the ruler and the showmatch
options.  The ruler option puts a row,column indicator in the status line at
the bottom of the file.  Although the documentation mentions that this can
slow performance a bit, I've found that it works with no noticeable delay
whatsoever.

<P>
The other option is showmatch, which highlights the matching brace, bracket,
or parenthesis as you type.  Be aware that it sounds a warning beep if you
insert a right brace/bracket/parenthesis without its opening mate.  This can
be a little annoying, but the time it saves you a syntax error, you'll be glad
for it.  I did a little bit of LISP programming this Spring in our Theory of
Programming Languages course and was mighty happy to use this!

<H3>Ahhh! Time For The Pictures!</H3>

Congrats!  If you've made it this far you might be interested in finally
having a look at all the good stuff that I've been mentioning here.

<P>
Here's the skinny...

<P>
What I did was create a number of screen dumps of gvim in action -- editing a
*.cc file (show off the syntax highlighting stuff...), using the online help
system (also shows the multi-window look), and displaying a manual page from
within gvim (&quot;Look ma! No hands...!&quot;).  I used the venerable
<B>ImageMagick</B> to make the thumbnail prints after using a combination of
<B>xv, xwpick, and xwd</B> to make the actual screen dumps and crop the pics.

<P>
Also, for the comparison shoppers out there, I've included similar screen
dumps of <B>XEmacs, GNU Emacs, NEdit, and XCoral</B> -- other very nice and
feature-rich editors that some of you will be familiar with.  All of these
provide syntax-highlighting and a set of extended features.

<P>
Finally, I've included a couple shots of the <B>xxgdb</B> and the <B>DDD</B>
debuggers.  I've been using both quite a bit lately and found that they are
absolutely indispensable for tracking down mischievous bugs.  I've included a
couple URL's below as well, but let's start with the Family Photo Album:

<H3>gvim Screen Shots</H3>

<P>
All of these are approximately 20k.

<P>
<A HREF="./misc/gvim.gif">
<IMG SRC="./misc/gvim-th.gif"      WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/gvim-help.gif">
<IMG SRC="./misc/gvim-help-th.gif" WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/gvim-man.gif">
<IMG SRC="./misc/gvim-man-th.gif"  WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>

<H3>The &quot;Other Guys...&quot;</H3>

<P>
All of these are approximately 20-25k

<P>
<A HREF="./misc/xemacs-19.15.gif">
<IMG SRC="./misc/xemacs-19.15-th.gif" WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/emacs.gif">
<IMG SRC="./misc/emacs-th.gif"        WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/nedit.gif">
<IMG SRC="./misc/nedit-th.gif"        WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/xcoral.gif">
<IMG SRC="./misc/xcoral-th.gif"       WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>

<H3>The xxgdb Debugger</H3>

<P>
<A HREF="./misc/xxgdb.gif">
<IMG SRC="./misc/xxgdb-th.gif"        WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>

<H3>The DDD Debugger</H3>

<P>
All of these are approximately 20-25k

<P>
<A HREF="./misc/ddd-2.1.gif">
<IMG SRC="./misc/ddd-2.1-th.gif"      WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/ddd-2.1-data.gif">
<IMG SRC="./misc/ddd-2.1-data-th.gif" WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>
<A HREF="./misc/ddd-2.1-msg.gif">
<IMG SRC="./misc/ddd-2.1-msg-th.gif"  WIDTH=158 HEIGHT=172 ALIGN=BOTTOM></A>

<P>
Let me make just a couple comments about the debuggers.

<P>
First, I've found both of these to be very usable and helpful in terms of
making debugging easier.  They are both front ends to the GNU GDB debugger (and
DDD can be used with a variety of other debuggers as well).  The xxgdb
debugger is the simpler of the two and probably is a good place to start
learning and tinkering if you've not used a graphical debugger before.

<P>
I ended up having to do a bit of tinkering with the resource settings for
xxgdb.  I'm currently using Fvwm95 with a screen resolution of 1024x768 and
8-bit color.  To get all the windows comfortably in 1024x768 I messed around
with the geometry resources.  Also, the file selection box was completely
whacked out -- I did a bit of adjustment to this to provide for a more sane
display.  If you're interested, here's the XDbx resource file I'm currently
using:

<H3><A HREF="./misc/XDbx.ad">Xxgdb resource file</A></H3>

<P>
Also, the DDD debugger shown above is the most current public release --
version 2.1 which just recently showed up in the Incoming directory at
sunsite.  I don't know if it'll still be there, but you have have a try.  If
you don't find it there, try the /pub/Linux/devel/debuggers subdirectory and
see if it hasn't been moved there.

<H3><A HREF="http://sunsite.unc.edu/pub/Linux/Incoming/">Sunsite Linux
Incoming Directory</A></H3>

<P>
Keep in mind that you probably <I>should</I> be using one of the sunsite
mirrors.  If there's one near you, then use it! :-)  There should be dynamic
and static binaries available as well as the source code.  In addition,
there's an absolutely HUGE postscript manual page with lots of nifty pictures
included in the /doc subdirectory in the source file.

<P>
I've not had a chance to use the new DDD debugger as much as xxgdb, but what
I've tried I'm been VERY impressed with.  You'll see from the screen shots
above that it has a much improved GUI as compared to xxgdb.  Also, a number of
new features have been added since the previous 1.4 release.  One feature that
I really like is setting a breakpoint, running the program, and then, by
positioning the mouse pointer over a variable or data structure, getting a
pop up balloon with the current value of that data structure.

<P>
This is huge. It rocks!

<P>
I really don't have time to talk about this, so you'll have to do a bit of
exploring on your own!  Also, note that the folks working on DDD are
encouraging the Motif-havenot's to either use the static binaries or give the
<B>LessTif</B> libraries a try.  Apparently, there have been some successes
using this toolkit already.  I'm sorry that I don't have the URL for LessTif,
but a Yahoo, Alta Visa, etc., search should turn up what you need.

<P>
And lastly (and this really is the last... :-), here's some URL's for the
editors listed above:

<H3><A HREF="http://www.math.fu-berlin.de/~guckes/vim/">VIM Home Page</A></H3>
<H3><A HREF="http://www.xemacs.org/">XEmacs Home Page</A></H3>
<H3><A HREF="ftp://ftp.x.org/contrib/">ftp.x.org FTP site (XCoral)</A></H3>
<H3><A HREF="ftp://sunsite.unc.edu/pub/Linux/X11/xapps/">sunsite.unc.edu
FTP site (NEdit)</A></H3>

<P>
The first two links should put you at the VIM and XEmacs home pages which
provide a wealth of helpful information about each of these excellent editors.
The last two I apologetically provide as approximate FTP links.  The first
will drop you into ftp.x.org in its /contrib subdirectory.  You should be able
to find the latest version of XCoral there, probably under the /editors
subdir.  The version shown above is version 2.5; the latest version of xcoral
is 3.0, which I've not had a chance to compile or tinker with.  The last link
will put you at sunsite in the /X11/xapps subdirectory.  Have a look in the
/editors subdir for the latest source or binaries for NEdit.

<P>
Phew! That was a <I>tour de force</I>!  Glad you hung in there!

<P>
I'd be happy to try to field questions about this stuff or hear back from
anyone with comments or suggestions about any of these excellent programs.

<P>
Hope you enjoyed!

<P>
John

<!-- END ARTICLE ================================================== -->

<P><HR><P>

<!-- ARTICLE ================================================ -->
<H2><A NAME="closing"><IMG SRC="../gx/fisk/desklamp.gif" WIDTH=79 HEIGHT=99
ALIGN=BOTTOM>Closing Up The Shop</A></H2>

<P>
Well, I apologize again for the brevity of this month's column.  I'd hoped to
do a bit more writing on a couple different things, particularly one of the
topics that's near and dear to my heart:  shell scripting.  I'm absolutely
convinced that learning even basic shell scripting will forever sour you to
DOS and will make you think twice even about the Windows stuff.  Shell
programming opens up a tremendous world of possibilities and, probably most
importantly, <I>it puts you in control of your system</I>.  It let's you do
all sorts of cool and groovy things that would be difficult or impossible
under a DOS/Win system.

<P>
As a quick example, I'd recently had an occasion in which I needed to format a
stack of 30-40 floppies (I was planning to do an afio backup of the XEmacs
distribution I'd spent several hours downloading) and decided to use
<I>superformat</I> to do this.  Now superformat is a great little program that
has the typical bazillion options.  Since I needed only a few of these options
for my particular system, I whipped together a shell script to help automate
this process.  It's no marvel of programming genius, but here it is:

<PRE>
#!/bin/sh
#
# fdformt.sh   formats 1.44 HD floppies in the fd0 drive
#
# Author:      John M. Fisk &lt;ctrvax.vanderbilt.edu&gt;
# Date:        6 May 1997

FORMAT_CMD=&quot;superformat -v 3 &quot;
FLOPPY_DEV=&quot;dev/fd0&quot;

while : ; do
    echo -n &quot;Format floppy [y,n]? &quot;
    read yesno
    if [ &quot;yesno&quot; = &quot;y&quot; -o &quot;yesno&quot; = &quot;Y&quot; ]; then
        echo -n &quot;Insert floppy and hit any key to continue...&quot;
        read junk
        ${FORMAT_CMD} ${FLOPPY_DEV}
    else
        break
    fi
done
</PRE>

Now, I'm sure that this could easily be improved upon, but the point was that
it took me all of about 3 minutes to write this, it's easily maintained, and
the logic is simple enough that it needs no documentation.

<P>
Why bring this up?

<P>
Well, I think this points to one of the larger issues with using and running
Linux:  <I>the sense of control</I>.  Thing is, under a Linux system, you have
an impressive arsenal of powerful and mature tools at your disposal that allow
you to do things with you system.  You can make it do what <I>you</I> need and
want it to do.

<P>
Don't get me wrong, I enjoy many of the features of the OS/2, Win95, and MacOS
OS's and I hope that the day will come when office suites and productivity
tools of the highest caliber exist for Linux as they do under these other
OS's.  The thing that sets Linux apart is the freely available set of powerful
tools that provide an unparalleled measure of freedom and control over your
system.

<P>
Think about it...

<P>
Shell scripting, Perl, Tcl/Tk, the entire range of GNU development tools and
libraries, and a suite of immensely powerful utilities and programs.

<P>
That's impressive.

<P>
Anyway, I'm preaching to the choir... :-)

<P>
Also, this is something of &quot;old news&quot;, but I wanted to thank the
folks at <B>RedHat Software, Inc.</B>, the LUG at <B>North Carolina State
University</B>, and the myriad participants in this year's <B>Linux Expo
'97</B>.  It was a blast!

<P>
A bunch of us from MTSU headed East and managed to get to most of the two day
affair.  All in all, with the minor exception of some parking problems, the
whole affair when smoothly and was VERY professionally done.  The talks were
delightful, the facilities very nice, and there were lots of great displays
and vendor booths to visit and check out the latest Linux offerings.  The book
tent out front cleaned out more than one person's wallet, sending them home
laden down with all sorts of goodies.

<P>
All in all, it was a great trip.

<P>
For anyone who went, I was, in fact, the annoying short nerdy looking fella in
the front row with the camera.  Sorry... :-)  

<P>
But, I just got the prints back and have sent a stack of them off to
<B>Michael K. Johnson</B> at RedHat.  Since I don't have a scanner or my own
web site, I figured the Right Thing To Do would be to send the doubles to the
guys at RedHat and let them put up anything they thought worthwhile.  If
you're interested in seeing who some of the various Linux folks are, drop
Michael a note and I'm sure that he'll help out.

<P>
Well, guess it's time to wrap this up.  I had a great year this year at MTSU
and am looking forward to finishing up school here one of these years :-).
I'm also looking forward to having a summer of nothing more than Monday
through Friday, 9:00 - 5:00.  I don't know about you, but I've always got a
long list of projects that I want to work on.  I'm really looking forward to
this.  I've finally started learning <B>emacs</B> -- actually, I've just
gotten the most recent public release of <B>XEmacs</B> and have been having
all sorts of fun trying to figure this one out.  My wife and I will be leaving
tomorrow for a couple weeks in Africa -- actually, Zimbabwe and Zambia.  Her
parents are finishing up work there and will be returning this Fall.  After a
busy year for both of us, we're excited about a vacation and the chance to see
them again.  I should be back by the time this month's LG &quot;hits the
stands&quot;, although if you wrote during much of May, be aware that I'm
definitely going to have a mail black-out! :-)

<P>
So... trust y'all are doing well.  Congrats to all of this year's grads!

<P>
Take care, Happy Linux'ing, and Best Wishes,

<P>
John M. Fisk<BR>
Nashville, TN<BR>
Friday, 9 May 1997<br>
<P><HR><P>

<IMG SRC="../gx/fisk/mailme.gif" ALIGN=MIDDLE WIDTH=38 HEIGHT=30> If you'd like, 
drop me a note at: 
<ADDRESS>John M. Fisk 
<A HREF="mailto:fiskjm@ctrvax.vanderbilt.edu">
&lt;fiskjm@ctrvax.vanderbilt.edu&gt;</A>
</ADDRESS>


<!--===================================================================-->
<P> <hr> <P> 
<center><H5>Copyright &copy; 1997, John M. Fisk<BR> 
Published in Issue 18 of the Linux Gazette, June 1997</H5></center>

<!--===================================================================-->
<P> <hr> <P> 
<A HREF="./lg_toc18.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif" 
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../lg_frontpage.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="./sybase.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./lg_backpage18.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P> 
<!--startcut ==========================================================-->
</BODY>
</HTML>
<!--endcut ============================================================-->