»
Tech Talk
»
Beyond the Basics
»
Subroutines Added
| Beyond the Basics |
|
Subroutines Added |
|
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration 
|
Great idea! I like this... definitely something that will be used repetitively in the future! (which, I'm sure, is why it exists!) http://63.144.246.54/test/form3.htm One big question regarding this...I actually got it to work on the second try! ...I looked into my server logs when it didn't work the first time, and it said the following quote: Ok... so I looked at the code (below) and added a second bracket at the end of the 'footer' subroutine... my question is why the hell did I have to do that? *confused look* ***** #!/usr/local/bin/perl &inputIn; #define variable names $userName = $input{'name'}; $email = $input{'email'}; $Sub = $input{'sub'}; #print page &header; print qq~<html><head><title>Testing Subroutines</title></head><body> <p>User Name is: <strong>$userName</strong></p> <p>Email Address is: <a href="mailto:$email">$email</a></p> <p>Submission:<br><br><strong>$Sub</strong></p>~; &footer; #sub to read and parse input and place into array sub inputIn { if ($ENV{'REQUEST_METHOD'} eq 'GET') { $form_info = $ENV{'QUERY_STRING'}; } else { read(STDIN, $form_info, $ENV{'CONTENT_LENGTH'}); } @input_pairs = split (/[&;]/, $form_info); %input = (); foreach $pair (@input_pairs) { $pair =~ s/\+/ /g; ($name, $value) = split (/=/, $pair); $name =~ s/%([A-Fa-f0-9]{2})/pack("c",hex($1))/ge; $value =~ s/%([A-Fa-f0-9]{2})/pack("c",hex($1))/ge; $input{$name} = $value; } #subs for html header and footer sub header { print "Content-type: text/html\n\n"; } sub footer { print qq~</body></html>~; } } ***** That's just plain weird if you ask me!  Why do I need one there, but not with any of the other subroutines? Okey-dokey smokey! LOL[/i]Would now be a good time to ask how to pass line breaks from the form, into the script, and back out to print?[/i] Thanks again Ron... the benefits to this particular exercise are likely by FAR more helpful than I could have imagined! Peace, C |
||
| © Copyright 2001 C.G. Ward - All Rights Reserved | |||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
quote:Addendum to this: Without using the <pre> tag (which with a few exceptions has proven far more trouble than it's worth to me... LOL), can we go into this little bit. I'm a-thinking that come payday, I'm due for a more comprehensive book on Perl & CGI. The two I have were certainly helpful, but hardly what I think I'm looking for. Any suggestions? |
||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Good job! quote: Right idea, wrong place to do it. You didn't "close" the inputIn subroutine with a brace, and THAT is why the compiler was complaining. By putting the closing brace where you did, you made the two shorter subroutines PART of inputIn. Everything in your program is global right now (scope is another chapter), so it doesn't hurt. It could hurt later… I would like to say I saw the source of the problem immediately, but that would be a lie. Tracking down matching braces can be a nightmare, especially in a complex program. Over the years, I've developed the habit of immediately closing a code block right after I open it. When I type the left brace, I hit return twice, type the right brace, then move my cursor up between them to add code. Indentation is also a big help (had you indented the big subroutine as you did the two smaller subroutines, the missing brace would have been obvious). Those don't help after the fact, however. To find your problem, I cut and pasted the code into my text editor, put my cursor on the last closing brace, and then pressed Ctrl-M. My text editor immediately highlighted the matching brace for me. The editor in question is TextPad and is well worth the download… quote: It already does that.  If you enter something in the Sub field with line breaks, click on the submit button, and then view the Source of the resulting HTML code - you should discover that the line breaks in the source correspond exactly to where you entered line breaks in the sub textbox. Trouble is, that's not really what you want. You want the browser to display line breaks as entered in the textbox - and as all HTML people know, that requires an HTML tag. Right after you assign the $Sub variable, lets add a substitution regexp: $Sub = $input{'sub'}; $Sub =~ s/\n/<br>/g; $Sub =~ s/\r//g; The first regexp substitutes our HTML tag for all line breaks in $Sub. If the data is coming from a Microsoft client, we have to deal with the old two-character problem (line feed / carriage return combination), so the second regexp just eliminates the second character. Your variable should now display properly in a browser. quote: Unfortunately, no. I looked for an entry level book, but never bought one. Perl is so close to C that I felt little need for help on syntax and it seemed like that was the emphasis in most books. When I do need syntax clarification (and I do), I look it up on-line. Here's a good source. The best way to learn, I think, is to simply do. But the second best way (since the first isn't always feasible), is to watch others do. I have downloaded hundreds of scripts from the Internet just so I could see how someone did something. And I've spent countless hours learning to understand and modify the code that makes up our forums (tens of thousands of lines). The big problem with this course, unfortunately, is the very real danger of picking up someone else's bad habits. And there are a LOT of bad habits out there, mixed in with the good ones. The one book I would recommend (and I wish I could find my copy) is The Perl Cookbook, a well organized compendium of real-world solutions, with pretty good discussions on how and why the code works. It's not meant to be a "teaching" text, but learning from it is almost inevitable. All good habits, and no bad ones. |
||
|
Kit McCallum
Administrator
Member Laureate
since 2000-04-30
Posts 14774Ontario, Canada |
Chris, I mentioned to Ron that I've been following you two along in these threads, and I'm really enjoying it. It's been quite a while since I've done some real programming - I started with DBaseIII Plus (years ago) and moved on to Clipper (actually to show my age ... I really started with WANG and glossaries which gave me the programming itch, LOL) - ouch! that hurt to admit that!  I wrote several programs in Clipper that we still use around the office from "time managment" which does billing and payroll, to oil industry specific programs that run our daily activities. We're in the process of converting these older programs (no easy task), and my programmer has been working on a client server database accessible to staff via the internet. I hope you don't mind, but I've been copying and printing some of your conversations from here for him in case these help him with a few frustrations he's run into over the last little while. It's a bit of a different world. Hope you don't mind me eavesdropping gentlemen, LOL. |
||
|
Ron
Administrator
Member Rara Avis
since 1999-05-19
Posts 8669Michigan, US |
Eavesdropping is cool, Kit. But you should jump in and start your own thread, ala the above. We can compare notes on extinct programming languages and I might even have a few suggestions for Rob to explore … |
||
|
Christopher
Moderator
Member Rara Avis
since 1999-08-02
Posts 8296Purgatorial Incarceration |
Most definitely cool mzzzZzz Kit! And actually, that reminds me (though completely off the subject...) didn't I read somewhere once that you deal with AutoCAD? Do you have any idea where I an find a script for converting EPS to DWG without having to deal with the pixellation that occurs with most of the ones I've found? Just curious. quote:And something I will definitely endeavor to do. I have to admit that I had to look a few times, even after you told me what the problem was, to find exactly where I missed it! And I can see how that could prove problematic in the future, were I to, say, copy just the inputIn sub into a new script! Then I'd be scratching my head again! LOL quote:On that, my friend, you will find me in complete agreeance. I'll even go so far as to say that for me, I have to do in order to learn. You can tell me all day how to do something, but I'll not be able to really understand until I start doing it. Trial and error is the best teacher for me. I do admit, though, that sometimes I want to take an actual class... LOL... but thankfully you're here to help me understand the parts I just can't quite grasp. For that, I'm immensely grateful! And actually, I've seen the Perl Cookbook. Barnes and Nobles has a whole section devoted to the O'Reilly books. When I first looked, though, I was a bit daunted adn opted for something that looked easier. In retrospect... well, no. What I did worked out well. You have to know the basics first. Perhaps it's just time now to move forward a little bit. (One step at a time, despite my inclinations to attempt flight before I build the wings...) Thank you! C |
||
|
Kit McCallum
Administrator
Member Laureate
since 2000-04-30
Posts 14774Ontario, Canada |
Chris ... I sent a note off to my friend to see if he has any suggestions on the autocad question. And thanks for not minding guys. I was self taught and at times the most aggravating little stumbling block left me spinning my wheels so hard the steam was rising off the top of my head. It felt like I just wanted to learn it "all" in one big swoop. I learned everything from books initially, but found later, that I was writing in "longhand" many of the times. I didn't know how to pass parameters to sub-routines and had a heck of a time with arrays. My first few programs were probably 20 times larger than they should have been from a source code standpoint ... but they worked, LOL. Around that time, a man joined our organization and basically helped me like Ron is here. It was funny, because I'd show him the working application doing what it was supposed to do which was fine ... but when I'd let him review my code, I swore I could hear a few audible grrrroans the first while as he showed me the "shorthand" versions. It's wonderful to have someone help you past those spots. Like Ron, one of the first things he suggested was that I follow the indenting of lines when coding to help me troubleshoot, and it was a lifesaver. For every bracket scenario or "IF" statement, I could follow it down in a logical line to the corresponding bracket, "ELSEIF" or "ENDIF" ... no more chasing and debugging in vain ... they eventually stood out very quickly once I got into that habit. Anyway, thanks for letting me read along. Maybe I'll start a thread like you suggested Ron, and we can chat about all that wonderful "old" technology that cost an arm and a leg. I even wrote a silly poem the day we retired the WANG VS, I'll see if I can scare it up for you, LOL. [This message has been edited by Kit McCallum (edited 05-26-2001).] |
||
|
Kit McCallum
Administrator
Member Laureate
since 2000-04-30
Posts 14774Ontario, Canada |
Chris, on the autocad question ... I don't know if this will help or not, but you can have a look. In our office, we've used a program called "Lucy" to convert scanned images into drawing files, dots into lines etc. If you're interested in having a look, there's a pretty good write-up at the page below with other software also that may be able to help. If you scan down to the end and choose Page 13 - you'll see a write-up on Lucy. http://www.cadonline.com/reviews/software/r2v/report.html |
||
|
|
⇧ top of page ⇧ |
|
| All times are ET (US). All dates are in Year-Month-Day format. | ||
