[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
Re: [MacPerl-WebCGI] Quoting body from a WWWboard posting
At 4:26 PM -0600 7/23/99, Linda Hardesty wrote:
>Thanks very much for the tip about Perl not needing < and > to be
>escaped. I thought your fix was very promising, but it didn't work
>because the text from the textarea has no <p>'s and no <br>'s. It
>does have an ascii 10 (Hex A) line break character where the typist
>has hit return. There is no special character where the text wraps
>on the screen.
>
>So, I replaced the <p> with the line break character that I copied
>out of the saved message. Now the script puts my quote character
>after line breaks, but of course it doesn't look too good because
>the text still wraps, but doesn't have quote characters in front of
>the wrapped lines. My question now is, do textareas work differently
>on Unix? - because this script on some web sites seems to work
>correctly.
>
>This code is part of where the message text file is created:
>
> print "Message:<br>\n";
> print "<textarea COLS=50 ROWS=10 name=\"body\">\n";
> $FORM{'body'} =~ s/</</g;
> $FORM{'body'} =~ s/>/>/g;
> $FORM{'body'} =~ s/"/"/g;
> print "$FORM{'body'}\n";
> print "</textarea><p>\n";
>
>It seems to expect the data receive from "submit" to have <,> and "
OK. now I see what's going on, although I'm not sure what to suggest,
as I've lost the sense of what your original difficulty was... :-)
What's going on above is the script is converting any HTML markup
that was submitted via the previous form's <TEXTAREA> box into
escaped text, and placing that text into a new <TEXTAREA> box on the
page the script returns to the browser. This really has nothing to do
with the line break problem you mention.
LINE ENDINGS
If someone hits return in the <TEXTAREA> box, or if the widget has
the attribute WRAP='physical' (inserting hard line breaks into text
that has wrapped in the box, without the user hitting return), then
line breaks will appear in the string held by $FORM{'body'}. And
those line breaks will be system-specific. UNIX, DOS/WIN, and Mac all
use different ways to express a line break (more correctly put as
"end of line" or EOL, but that's a logical concept, not a particular
character or phrase).
End of Line in Internet text-handling:
OS Perl Escape Char Octal
-- ---------------- -----
Mac \r \015
UNIX \n \012
DOS/WIN \r\n \015\012
Perl uses \n to localize the end of line to whatever system it's
running on. The following substitution will localize a file from
whatever source:
$line =~ s/\015\012|\012|\015/\n/g;
More efficiently:
$line =~ s/\015\012?|\012/\n/g;
Now, this isn't just useful for localizing. When I want to catch
<TEXTAREA> input and strip out the EOLs, I use the same match and
substitute in a phrase or character that serves my purpose, a la:
$FORM{'body'} =~ s/\015\012?|\012/ - AND - /g;
So if the user typed something into the <TEXTAREA> box, and hit
return, the substitution replaces each return with ' - AND - ' so the
text ends up all on one line that I can store or process further.
A <TEXTAREA> box:
_______________________________________
|I think your site is really cool! | <--User hit return
|How did you know my name?? | <--User hit return
| | <--User hit return
|I'll be back to buy lots of stuff! |
_______________________________________
Whatever OS the server is, the substitution above converts this to:
I think your site is really cool! - AND - How did you know my name??
- AND - - AND - I'll be back to buy lots of stuff!
[Note: the above is supposed to be all one line; emailing it might
have broken it into 2.]
This is just an example of how to cope with <TEXTAREA> line endings.
Incidentally, the EOL differences are embedded deep in the different
OSes, so please take this advice about them: a) write down or
memorize what they are, rather than trying to understand the
differences in some *logical* framework; b) don't waste time
complaining about the weirdness of the differences or proposing that
the OSes be changed (much less that [Mac]Perl be changed). Just write
code to handle the conversions you expect the script to encounter. If
you want to hear more about this, search the MacPerl list archives,
or take a look at Chris Nandor's discussion, at
<http://pudge.net/macperl/perlport.html#Newlines>.
THE BIG PICTURE
But let's pull back to the big picture. At this point, if you want to
stick with WWWBoard, I'd suggest that you start over with a fresh
download of the script, and focus only on the settings that the
documentation tells you to deal with. Try to get it to work just the
way the on-line examples do, before attempting to modify the script's
functionality.
The questions you've been posting are so specific to snippets of the
script that it's impossible to be of any help, and (no offense :-) it
appears you're flailing at the Perl rather than systematically
testing the setups. It takes some discipline, but the best way to
proceed is to make just *one* change at a time, test, think about the
error messages, and look again. Take notes as you go. Keep copies of
versions reflecting your accumulating changes (script1.cgi,
script2.cgi, script3.cgi, etc.), so you can back up and try something
else without making hash of the script (and I don't mean a Perl hash
;-).
Hope this doesn't sound like I'm lecturing -- I'm speaking from my
own experience when I started scripting CGIs 4 years ago. My
harsh-sounding remarks yesterday about Matt Wright's scripts weren't
about whether his scripts work at all, but rather that they *do* work
well enough that people use them and only later discover the security
holes and other problems. So, if I were you, I wouldn't go at it
assuming the script is faulty.
I start my students writing much simpler CGI scripts, and get them
familiar with <FORM> data handling, file operations, and regular
expressions/substitutions piece by piece, before tackling a complex
project like a web board. A major lesson is learning to use what the
worldwide network of Perl programmers have already created and
tested. If you want to take this approach rather than rolling your
own from scratch, start with the more recent and proven building
blocks I mentioned yesterday, cgi-lib.pl and, especially, CGI.pm.
If you want "out-of-the-box" CGIs, then a) first ask your server
admin what they provide; b) try an on-line source like Selena Sol,
<http://www.extropia.com/>, whose scripts started out as rough as
Wright's several years ago, but who has continued to develop and
*support* them over the years; c) read and follow the documentation
provided.
Good luck!
1;
- Bruce
# ~~~~~~~~~~~~~~~~~~~
# Bruce Van Allen
# bva@cruzio.com
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Director
# WireService, an Internet service bureau
# Serving the educational and nonprofit sectors
# wire@wireservice.org
# http://wireservice.org
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org