editing perl script through TEXTAREA

[anita]

Hello
I am trying to get to edit my perl scripts through a form. I'm loading
the perl script into the TEXTAREA, but the browser interprets the
stuff in the edit box. so if it happens to see another </TEXTAREa>
area in the text, it assumes it has found the end of the textarea and
the rest of my script is just spit out on the screen outside of the
textarea.
I can replace the > and < with HTML entities, while displaying and
whenthe user edits the fields, reinterpret the &entity back into > <
before saving.
My question is this- is there anything else I need to interpret before
I save ?
Like all those innumerable special chars in perl ?!

I realize this is strictly not a PERL question but would appreciate
any feedback. Especially if there are already some modules I can use
to do this sort of thing.
Thanks
anita

 

[Tore Aursand]

I am trying to get to edit my perl scripts through a form. I'm loading
the perl script into the TEXTAREA, but the browser interprets the stuff
in the edit box. so if it happens to see another </TEXTAREa> area in the
text, it assumes it has found the end of the textarea and the rest of my
script is just spit out on the screen outside of the textarea.

Check out the HTML::Entities module. It will let you encode any "special"
characters to HTML.

 

[Gunnar Hjalmarsson]

I am trying to get to edit my perl scripts through a form. I'm
loading the perl script into the TEXTAREA, but the browser
interprets the stuff in the edit box. so if it happens to see
another </TEXTAREa> area in the text, it assumes it has found the
end of the textarea and the rest of my script is just spit out on
the screen outside of the textarea.
I can replace the > and < with HTML entities, while displaying and
whenthe user edits the fields, reinterpret the &entity back into >
< before saving.

If you save before converting to HTML entities, you don't need to
convert those characters back.

My question is this- is there anything else I need to interpret
before I save ?
Like all those innumerable special chars in perl ?!

I realize this is strictly not a PERL question but would appreciate
any feedback. Especially if there are already some modules I can
use to do this sort of thing.

I'm not sure if there is a *need* to convert any other characters for
this limited purpose. However, this is a function I'm using:

sub entify {
my $ref = defined wantarray ? [ @_ ] : \@_;
for ( grep defined, @$ref ) {
s/&/&amp;/g;
s/"/&quot;/g;
s/</&lt;/g;
s/>/&gt;/g;
}
@$ref > 1 ? @$ref : $$ref[0]
}

Besides < and > it converts & and ".

There are also modules, of course, such as HTML::Entities, or you can
use the escapeHTML() function in CGI.pm.

HTH

 

[Tad McClellan]

I am trying to get to edit my perl scripts through a form.

Why are you trying to get to edit your perl scripts through a form?

I am sensing an X-Y problem here...

 

[anita]

Lets just say I am editing some file, any file through the form... Not
necessarily a perl script. That- is a good example because it tends to
have a lot of special characters.
One other person suggested that I save before converting. I am not
sure what was meant by that.

From what I understand, my file has to be processed to replace all the
special HTML chars before display (so browser wont complain) and once
the user edits and tries to save it through the form, it has to be
stripped off the special entities, so it can be saved...

I will look into the HTML module.

I am sensing an X-Y problem here...

I dont get it. What do you mean X-y problem ?
Thanks

 

[anita]

Lets just say I am editing some file, any file through the form... Not
necessarily a perl script. That- is a good example because it tends to
have a lot of special characters.
One other person suggested that I save before converting. I am not
sure what was meant by that.

From what I understand, my file has to be processed to replace all the
special HTML chars before display (so browser wont complain) and once
the user edits and tries to save it through the form, it has to be
stripped off the special entities, so it can be saved...

I will look into the HTML module.

I am sensing an X-Y problem here...

I dont get it. What do you mean X-y problem ?
Thanks

 

[Tad McClellan]

Lets just say I am editing some file, any file through the form...

I dont get it. What do you mean X-y problem ?

An XY problem is when you want to do X, but you ask how to do Y
instead, because you've decided that Y is the best way to accomplish X.


If you tell us why you think you want to edit programs in a browser,
then maybe we could suggest a better or easier alternative...

 

[gnari]

anita ([email protected]) wrote on September MCMXCIII in
<URL:--
-- I am trying to get to edit my perl scripts through a form. I'm loading


That sounds about as cumbersome and useful as eating soup through
the keyhole of a door.

naw, you just use one of those bendy straws.

gnari

 

[Gunnar Hjalmarsson]

One other person suggested that I save before converting. I am not
sure what was meant by that.

Suppose I'm that "other person". Post your code if you want me to
explain further.

From what I understand, my file has to be processed to replace all
the special HTML chars before display (so browser wont complain)

No, your file does not need to be processed. Your *data*, whereever it
come from, need to be processed before display.

and once the user edits and tries to save it through the form, it
has to be stripped off the special entities, so it can be saved...

No. The form takes care of that.

 

[Tore Aursand]

Lets just say I am editing some file, any file through the form... Not
necessarily a perl script. That- is a good example because it tends to
have a lot of special characters.

You still want to use the HTML::Entities module. Here's an example for
you to (hopefully) learn from (untested):

#!/usr/bin/perl
#
use strict;
use warnings;
use HTML::Entities qw( encode_entities );

my $data = 'whatever'; # This is very you read the data you want to
# convert to HTML from a file or something.

$data = encode_entities( $data ); # Convert any "special" characters
# to HTML entities.

# Do whatever you need to do with the converted $data variable.

 

[Gunnar Hjalmarsson]

Suppose I'm that "other person". Post your code if you want me to
explain further.

Second thought: The test.pl script below should explain the logic that
is my starting-point.

#!/usr/bin/perl -T
use strict;
use warnings;
use CGI::Carp 'fatalsToBrowser';
use CGI 'escapeHTML';
my $q = new CGI;
my $in;

my $file = 'file_to_edit.txt';

if ($ENV{REQUEST_METHOD} eq 'POST') {
$in = $q->Vars;
} else {
if ( open my $f, $file ) {
$in->{content} = do { local $/; <$f> };
} else {
$in->{content} = '';
}
}

open my $f, "> $file" or die $!;
print $f $in->{content}; # here it's saved ...
close $f;

$in->{content} = escapeHTML $in->{content}; # and here it's converted

print $q->header;
print <<FORM;
<form action="test.pl" method="post">
<textarea name="content" cols="50" rows="25">$in->{content}</textarea>
<br>
<input type="submit">
</form>
FORM

__END__

 

[ctcgag]

Lets just say I am editing some file, any file through the form... Not
necessarily a perl script. That- is a good example because it tends to
have a lot of special characters.
One other person suggested that I save before converting. I am not
sure what was meant by that.

From what I understand, my file has to be processed to replace all the
special HTML chars before display (so browser wont complain) and once
the user edits and tries to save it through the form, it has to be
stripped off the special entities, so it can be saved...

From what I understand, the textarea() sub (or method) of CGI module will
automatically do this conversion for you on the way to html, and the
param() sub or method (or something upstream of it) will automatically
do the reverse conversion on the way back.

Xho

 

[Gunnar Hjalmarsson]

From what I understand, the textarea() sub (or method) of CGI
module will automatically do this conversion for you on the way to
html,

Sounds plausible.

and the param() sub or method (or something upstream of it) will
automatically do the reverse conversion on the way back.

Don't understand. What do you mean by that?

 

[gnari]

Sounds plausible.


Don't understand. What do you mean by that?

he means that a character like '&' will be sent by
the browser encoded (&amp, but param() will
return it as '&' again.
so if you use textarea() and param(), you never have to
worry about it.

gnari

 

[Gunnar Hjalmarsson]

he means that a character like '&' will be sent by the browser
encoded (&amp, but param() will return it as '&' again.

There is a lot of confusion here.

A '&' character that is submitted via a textarea control is URI
encoded, not converted to the corresponding HTML entity. Accordingly,
after URI decoding, it's still a '&'.

It's when you want to display content initially in a textarea field
that you should first convert certain characters to HTML entities, but
if you for instance have:

<textarea name="demo">Smith &amp; Son Co.</textarea>

the browser will convert the '&amp;' to '&' and display it as '&'
right away, i.e. before submitting.

So my point, which I also tried to illustrate with a little program
in another post in this thread, is that there is never a need for the
Perl program to do any "reverse conversion" of HTML entities.

so if you use textarea() and param(), you never have to worry about
it.

No comments.

 

[Alan J. Flavell]

There is a lot of confusion here.

Nothing new there, then... :-}

A '&' character that is submitted via a textarea control is URI
encoded, not converted to the corresponding HTML entity. Accordingly,
after URI decoding, it's still a '&'.
Agreed.

It's when you want to display content initially in a textarea field
that you should first convert certain characters to HTML entities, but
if you for instance have:

<textarea name="demo">Smith &amp; Son Co.</textarea>

the browser will convert the '&amp;' to '&' and display it as '&'
right away, i.e. before submitting.

Spot on.

So my point, which I also tried to illustrate with a little program
in another post in this thread, is that there is never a need for the
Perl program to do any "reverse conversion" of HTML entities.

As a matter of principle you're correct here. But that isn't quite
true in practice, as I'll deal with in a moment.

As usual, it's all a matter of dividing the problem up into its
component parts, and understanding how each one works separately,
before assembling them into a working application.

But, over and above this, if folks go pasting weird characters into
their form submission (and there's no way you can stop them doing so),
then browsers do strange things with them. As the Perl Encode
documentation so engagingly remarks:

It is beyond the power of words to describe the way HTML
browsers encode non-ASCII form data.

- http://www.perldoc.com/perl5.8.0/lib/Encode/Supported.html

And there are some browsers (or should I say "browser-like operating
system components"?) which, when the user feeds into a form a
character which cannot be represented in the prevailing character
encoding, will turn it into or even into &entityname; format
for submission.

On arrival at the server, of course, the server-side process can have
no idea whether the user typed just a curly-quote character, or typed
the ASCII string “ (ampersand, hash, 8, 2, 2, 0, semicolon). By
that time they are indistinguishable. The behaviour in this situation
is undefined anyway, and browser developers have addressed it in
various different ways as they saw fit.

But Perl is only a small part of this problem - the major issues
really need to be hammered out on a suitable WWW-related group.
Where one might even get referred to my no-longer-quite-new
tutorial-ish page on the topic,
http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html

have fun

 

[Gunnar Hjalmarsson]

And there are some browsers (or should I say "browser-like
operating system components"?) which, when the user feeds into a
form a character which cannot be represented in the prevailing
character encoding, will turn it into or even into
&entityname; format for submission.

Now we are talking i18n it seems...

On arrival at the server, of course, the server-side process can
have no idea whether the user typed just a curly-quote character,
or typed the ASCII string “ (ampersand, hash, 8, 2, 2, 0,
semicolon).

Not even CGI.pm's param() function/method, I presume. ;-)

 

[anita]

Sorry did not mean to offend you with "Other person" remark!
Anyway I think I get it now- script makes it very clear.
Basically the browser sends back whatver it has DISPLAYED when I say
submit, not what is in the source. I kept thinking that if it sent the
browser say a &lt and displayed it as <, then when it came back it
would still comeback as &lt. Now I see it does not. So what comes back
is the display of &lt ie., <

That way the conversion returns it to &lt before saving it again.
And if the user typed in &lt, that will be sent in as &lt and after
conversion gets becomes &amp;lt, so gets displayed the same as the
used typed in.

Thankyou
Anita

 

[Gunnar Hjalmarsson]

Sorry did not mean to offend you with "Other person" remark!

No problem, I was not offended. ( I see now that my harsh comment may
have made you believe otherwise. Sorry. ;-) )

Basically the browser sends back whatver it has DISPLAYED when I
say submit, not what is in the source.

Yes, it does. (With the exception of what Alan let us know about
certain internationalization issues...)

That way the conversion returns it to &lt before saving it again.

Suppose you mean before displaying it again...

And if the user typed in &lt, that will be sent in as &lt and after
conversion gets becomes &amp;lt, so gets displayed the same as the
used typed in.

Yep.

 

[Alan J. Flavell]

Now we are talking i18n it seems...

If you want to interpret it that way, yes. But many devotees of Bill
have no idea that curly quotes, trademark signs etc. can lead to such
complications; they type them in quite happily on the client side
(there's nothing you can do to prevent them), and then when it gets to
the server side process, it's left to the programmer to pick up the
pieces. That was the issue that I was trying to bring out in this
comment.

Not even CGI.pm's param() function/method, I presume. ;-)

You know as well as I do that CGI.pm isn't telepathic: it gets fed
exactly the same data stream as any other CGI process would get fed.

It's a pity that an extension mechanism to the %xx URL encoding
definition didn't get defined in good time, to deal with this
situation unambiguously (analogous to Perl's wide character
constants).