>Okay - this gives me a chance to ask another question... I'm having a bit >of a rough time grasping calling subs and how values are passed and then >returned to/from the subroutine. Basically, anything you put in parentheses when you call a subroutine is accessed in @_ in the body of the subroutine. That's it, there are no other special rules. In my case, my subroutine print_content_type takes the first argument passed to it (which should be the only argument) and stores it in its local copy of the variable $ct: >sub print_content_type >{ > local($ct) = @_; > $ct = "text/html" if !$ct; > print "Content-type: $ct\n\n"; >} That local copy is unrelated to whatever variable is passed in, except that they happen to have the same value. So when I call it with: > &print_content_type($ct); That could just as well be: > &print_content_type("text/plain"); or > &print_content_type($my_content_type); or whatever. The fact that, in my code, the global variable $ct happens to have the same name as the local variable in print_content_type is coincidence. >I'm also trying to write a subroutine that takes a long string, and >returns it split up into a hash. The way I want to call it is: > >%form = &splitter($longthing); > >[...] Everything I've seen just calls the subroutine, and the subroutine >itself returns the %FORM stuff - I'd rather assign it in the main section >of the program, where I can make the subroutine more portable, by being >able to interchange above with something like > >%order = &splitter($submission); Well, you could do this, but it's a little odd since one doesn't normally return associative array values from a subroutine. Since assigning a list to an assoc. array will store it paired off, key, value, key, value, you could probably do this if you wanted to. But it's better to use a typeglob. Go check out the camel book, p. 101, for more information on that -- I won't try to explain it in email :-) I find it's no big deal to have a standard library routine that splits a form submission into an assoc. array of standard name. Why would you want to have different names for every CGI you write, except to make things more confusing for the maintainer? >>Reading to and printing from a buffer of fixed size will give more >>predictable results than "while ($image=<GIF>)". > >Is there any particular reason you used a 16k buffer? Nope -- just guessed. >Perl is >amazingly powerful for even the simplest of jobs, Yup ;-) -- Jamie McCarthy http://www.absence.prismatix.com/jamie/ jamie@voyager.net Co-Webmaster of http://www.nizkor.org/ Hate mail will be posted.