RE: Inserting a Form Feed Using a Format Statement
The ASCII code for a formfeed is 12 so you should be able to embed that in a string as
'\xC' I haven't tried it myself but it works for newlines and carriege returns.
-Original Message-
From: Theresa Mullin [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 15:53
To: [EMAIL PROTECTED]
Subject: Inserting a Form Feed Using a Format Statement
Hi everyone,
I'm writing what I thought would be a really quick program to print
course information across the top of our Course Evaluation forms.
I'm using a format statement to get the spacing just right on the
output, but I can't get it to insert the form feed character at the end.
I've tried setting the $FORMAT_LINES_PER_PAGE ($=) to 1, among other
things, and nothing seems to work. When I print out the data, I still
get the whole list on one page.
Here's a little snippet of my code:
$= =1;
### Format for output
format EVAL_OUT=
@ @ @
$full_name,$crse_numb, $seq_numb_ssbsect
.
select (EVAL_OUT);
sub print_rec_to_output_file
{
write();
}
Any and all help is appreciated.
Thanks,
T.
Theresa Mullin
Programmer/Analyst
Administrative Computing
Northern Essex Community College
100 Elliott St.
Haverhill, MA 01830
(978) 556-3757
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
directory help
Hello,
I am writting a script to find and link to all the files through out a
whole website.
I have had trouble with finding and opening directories on a winNT system,
does anyone have a idea on how to find and open all directories and
desplay their contents?
my code...
$base = c:\\www\\; # the www is where the files are held on the unix
server
sub openDir {
opendir(BASE, $base) || print Error...;
while ($name = readdir(BASE)) {
if (-d $name) {
print a href =$name target=otherpage$name/a
opendir(NEW, $base$name) {
...
the -d doesnt' find the directories on the windows system, and I haven't
had the chance to try it out on the unix server...
any ideas on a work around?
thanks for your time,
James
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mod_perl books, cpan modules.
I want to learn mod_perl and there're two books who talk about this. Now a third has arrives and it's talking about 2.0 mod_perl but i am a Lincoln Stein fan and i want the Writing Apache Modules with Perl and C. But the last edition is still about 1.3, anyone knows anything about any intention about making a super-new edition about 2.0?? Another question about cpan modules, only very few are really classes aren't them? i mean, oop is still rare in cpan? or i'm wrong and all new modules get rid of exporter.pm?? http://www.perlattack.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl books, cpan modules.
On 20 Mar 2003 09:33:56 -, entius [EMAIL PROTECTED] wrote: I want to learn mod_perl and there're two books who talk about this. Now a third has arrives and it's talking about 2.0 mod_perl but i am a Lincoln Stein fan and i want the Writing Apache Modules with Perl and C. But the last edition is still about 1.3, anyone knows anything about any intention about making a super-new edition about 2.0?? I don't do a lot of mod_perl but I would think that the basis for how the various steps in a request/response are handled, etc. are very similar between the two versions, so the underlying core of the book mentioned above would still apply, with various changes in syntax for the interface, etc. I will comment that when I went through the book a little over a year ago it was excellent for anyone with a good background in Perl and its use on the web. Another question about cpan modules, only very few are really classes aren't them? i mean, oop is still rare in cpan? or i'm wrong and all new modules get rid of exporter.pm?? This I would disagree with currently, though I couldn't say when a critical mass was reached, though obviously I feel it safe to say that much of the OOP is concentrated in newer modules. And part of the beauty and flexibility of the Perl OOP model means it only requires a little more effort to make a module both OOP and non-OOP. the CGI.pm is a perfect example, for those from the old school they will find CGI fits their purposes and provides all of the same functionality, that it does to those that prefer the OOP approach, through virtually the same interface. Some other examples include the Mail::Box module for all things mail oriented, it is extremely extensive and uses Perl's OOP tactics to the fullest. POE, Crypt::OpenPGP, DBI, and then the obvious examples of things like Class::MethodMaker that handle building much of the OOP interface for you (isn't Perl grand!). I think it is dangerous to think of OOP and using the exporter as mutually exclusive however... http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to block out BGCOLOR
What about the user says :
body
text=#123456
bgcolor=#aabbcc
or
body bgcolor='#123456'
or
body bgcolor=
red
Anyway, the bgcolor can be formed or change again via javascript or CSS.
I mean, blocking bgcolor in body tag cannot solve your potential problem.
But you may find someway to put this in your body tag :
background=white_block.jpg,
as wallpaper goes upper than bgcolor or using javascript :
document.bgColor='ff'; // not sure if this run on NS too
In Perl way, I can't provide any code here because I don't know when you
want to
block that bgcolor .. On the print time ? or at the html file's landing
time...
Anyway, if you just don't want your users to use bgcolor in the body tag,
just simply $line =~ s/bgcolor/whatever_you_like/;
Once the browser don't understand something not in list of its properties,
will be ignored... I mean, don't care on the RHS of =, but the LHS, unless,
you are trying to fulfill W3C's html standard.
Regards,
Perl Beginner
no, the problem is on the other side of the = token
eg:
body bgcolor=#99
or
body bgcolor=red
or
body bgcolor=red
and he would like to make that
body
I would of course go with say:
#
#
sub un_colour {
my ($line) = @_;
$line =~ s/\s*bgcolor=(?)([^\s]+)(?)//gi ;
$line;
} # end of un_colour
since the middle element needs to guard against
a.
b.
c. white space
ciao
drieux
---
my $l1 = 'bodybgcolor=#99 other=fred
stuff here
table bgcolor=blue
';
my $l2 = 'body bgcolor=red other=fred';
my $l3 = 'body bgcolor=red other=fred';
foreach my $tag ( $l1 , $l2 , $l3 )
{
my $answer = un_colour($tag);
print #---\n$answer\nfor $tag \n;
}
#
#
sub un_colour {
my ($line) = @_;
$line =~ s/\s*bgcolor=(?)([^\s]+)(?)//gi ;
$line;
} # end of un_colour
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to block out BGCOLOR
Hello World Li Ngok Lam's approach looks good to me. Using the $line=~s// approach appears to be only removing the bgcolor word correctly but could be stuck on the different types of colour descriptor used. Is it RGB, hex or a word? Putting a background color descriptor in though allows you to change the image to a white or transparent gif file quite simply. You can still use the default background where needed. JimmyG -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to block out BGCOLOR
volks,
brief prefix. I believe Li Ngok Lam has found a clear
'issue' in the original request for solving a regex problem.
my working assumption was that the OP needed a filter that
would clean up a bunch of pre-existing static *.html files
because the site had adopted a new scheme, and so these older
pages would merely need to be 'cleaned'
But since some here may also have scratched their heads at the
original request let's step aside for a moment and look at some of the
issues
On Friday, Mar 21, 2003, at 09:05 US/Pacific, Li Ngok Lam wrote:
[..]
Anyway, the bgcolor can be formed or change again via javascript or
CSS.
I mean, blocking bgcolor in body tag cannot solve your potential
problem.
This of course is the 'critical kill' in the OP's problem.
In terms of trying to 'control it all' from some CGI script
that is 'generating' web pages given various 'input streams'.
{ hey, we all started some place. And figured out our better
ways along the way... }
Let's deal with the CSS/SSI side plays first, as the
javascript side is modestly easier to solve.
There are CSS as well as various SSI directives, which,
were we to seek completeness would require that a much
more complex parser be in play, since it would need to
deal with each of them in turn - and DOING the 'resolve
in place' - eg given
head
meta http-equiv=content-type content=text/html;charset=ISO-8859-1
titleWelcome/title
link href=../CSS/sitewide.css rel=stylesheet media=screen
/head
the parser would need to grot through the *.css file and
resolve if there is any bgcolor components, if clean,
let it stay, otherwise that part of the text would need
to be reconstructed and pushed into the data stream:
htmlheadtitle Welcome /title
style
!--
body { font-family: Arial, Helvetica, Geneva, Swiss, SunSans-Regular }
p { font-size: 12px; font-family: Arial, Helvetica, Geneva, Swiss,
SunSans-Regular }
td { font-size: 12px; font-family: Times New Roman, Georgia, Times }
element { }
//--
/style
/head
We of course would not need to put the static 'content-type'
in a dynamic stream back to the web browswer, since as a
perl CGI script, we of course need to send out the
print Content-Type: text/html;charset=ISO-8859-1 $CR$LF
anyway, right???
But you may find someway to put this in your body tag :
background=white_block.jpg,
while we are proposing the idea of replacing, it is
important to remember that the 'background' attribute is
'acceptable' in more than just a body tag... But you
probably would not want to ship a src such as a jpg file
in the process if all you really want to do is redefine
to say white eg:
bgcolor=#ff
the RegEx I proposed would of course remove the string
background=white_block.jpg
from any 'input' provided since it really does not
care about whether those are alpha-numeric, or not,
since it was designed to remove the stuff after the =
as it were...
as wallpaper goes upper than bgcolor or using javascript :
document.bgColor='ff'; // not sure if this run on NS too
[..]
this part of the problem is where one needs to expand the
RegEx as well, so that one deals with the possible contamination
in a javascript element, most likely triggered by the 'onload'...
But the 'patterns'
document.bgColor
document.background
etc, could likewise be 'targetted' for conversion, on the
fly, and/or 'in place' with the same type of filtering
with an appropriate RegEx.
The trick in those cases of course is that javascript
allows white space on either side of the = so one is
looking at the problem of
$line =~ s/document.bgColor\s*=\s*([']?)([^^'\s]+)([']?)\s*(;?)//gi
;
in this case, since single or double quotes would be possible
HTH.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to block out BGCOLOR
Just so everyone knows, it was for a print friendly part of a CMS-type script. With all your help, it was solved, with a regex. It wasn't just for the body tag, It is for EVERY tag, and I blocked the BGCOLOR, BACKGROUND, STYLE, CLASS, ID, COLOR, and more attributes to totally make the page both dull and print friendly. My problem was with my Regex, which was: $blah =~ s/ bgcolor=(?)(.*?)(?)//gi Shortly after posting, I solved it myself with $blah =~ s/ bgcolor=(?)(.*?)( |)/$4/gi; I doubt that would have held up. My new one thanks to drieux is: $blah =~ s/\s*bgcolor=(?)([^\s]+)(?)//gi ; Thank you for your help everyone. William Gunther
