exposed to new minds; my own Perl and shell tutorials (it turns out that
     somehow one of the articles I wrote for it never got published!), too.
     Yes, people can find them in the old issues - but I suspect that many of
     our readers don't go trolling through the archives but just read us once a
     month.

     (If anyone's got suggestions on a previous article that's worth dusting
     off, my mailbox is always open.) -- Ben

   The only thing I'd like to see is how to build/design a program in for
   Linux, don't care what language, just how to design, program and test it,
   to give a good correct program. 

     [grin] See those very tutorials that I've mentioned. I suggest starting
     with shell scripting and climbing up from there. -- Ben

   My Amiga programs were very simple, single user affairs, and I really don't
   get OOP and multi user stuff yet. I mean how do you prevent buffer over-runs
   and memory loss for example. 

     Those aren't an issue in the modern scripting languages (shell, Perl,
     Python, etc.) In C, well, see my response to Tom. Unless you really know
     what you're doing, C can be very dangerous indeed. -- Ben

     [Tom Brown] Tip: If you want to learn how to program in OOP, spend a
     little time learning Borland's Delphi (it uses a Pascal variant). It has
     nearly all the power of C++, and is easier to use than Visual Basic. Once
     you get all the C++ syntax out of the way, you'll learn OOP in no time.
     Then you can move on to something like C++, Java, or C#. I had the same
     trouble you did, and that's what worked for me.

     [Jimmy O'Regan] You mean Kylix, which is the Linux version. There's also
     the Lazarus IDE ([36]http://www.lazarus.freepascal.org) for Free Pascal
     ([37]http://www.freepascal.org).

     I've snipped a bit of replies that were a sideline about programming
     details themselves - with the Gang chiming in, it might make a good thread
     or an article in upcoming months. -- Heather

   In the meantime, I shall continue to enjoy your magazine. 

   Some other thoughts: Get more people to link to you and advertise your site
   more, most people would do it out of gratitude for all the good work you
   guys do. 

     Something like that is in process now; it's one of those things that I
     mentioned discussing with Heather. -- Ben

   Find every occurence of the .com one and get a link to your site on there as
   well - surfers will compare sites and you'll win hands down! 

     Thanks. A couple of our people were doing just that, right after the
     separation. -- Ben

   Take care and all the best, 

   Steve Brown 

   Note: I had to use a Hotmail account (yeuchh) as my dog took a fancy to
   copper cored wire and ate every single wire sticking out the back of my
   box, he only left me with a monitor lead. Next time I'm gonna leave it
   switch on. 

     [laugh] If you write it up and send it to me, it'll end up in "The Foolish
     Things We Do With Our Computers" column sometime soon. -- Ben

     ...and indeed, you can see it here! Any foolish things you've done to your
     computers? Send 'em in... -- Heather
                                  _______

   Hi Ben, thank you for the reply. 

   I'll keep an eye out for those tutorials. I've got the O'Reilly Learning
   Perl Book and I'm still getting over the stage of "it looks like garbage",
   familiarity  will sort all of that out no doubt. I seem to recall your
   one-liner articles, I found those fascinating as they demonstrated the
   problem solving methods you use, and gave a good insight in how to use
   what's already there. 

     [Ben] Actually, I was talking about my 5-part "Learning Perl" series. Take
     a look at [38]http://linuxgazette.net/authors/okopnik.html .

   Aahh, I'd forgotten about these gems, thank you. 

   I'm glad to see that buffer overruns etc. are not a problem in Perl or
   Python, I'll just avoid C, I'm most familiar with it as a language but it's
   some time since I actually used it. Thanks for the example program, I'm
   looking forward to looking at that and trying to work out why it isn't
   correct. 

     [Ben] As Thomas has already noted (something I originally missed due to
     being tired and mostly asleep), it's a buffer overflow due to strncpy not
     terminating the string - a truly idiotic design decision. From libc's
     info:

 - Function: char * strncpy (char *restrict TO, const char *restrict
          FROM, size_t SIZE)
     This function is similar to `strcpy' but always copies exactly
     SIZE characters into TO.