[18230] in Perl-Users-Digest
Perl-Users Digest, Issue: 398 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 2 14:10:39 2001
Date: Fri, 2 Mar 2001 11:10:13 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <983560213-v10-i398@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 2 Mar 2001 Volume: 10 Number: 398
Today's topics:
Perl unpack() function? How to use? <djpoot@kabelfoon.nl>
Re: Perl unpack() function? How to use? (Rafael Garcia-Suarez)
Re: Perl unpack() function? How to use? (Anno Siegel)
Re: Perl unpack() function? How to use? <flavell@mail.cern.ch>
Re: Perl unpack() function? How to use? (Rafael Garcia-Suarez)
Re: Perl unpack() function? How to use? <djpoot@kabelfoon.nl>
Re: Please help - Find files recursively by File::Find (Anno Siegel)
Re: Please Help with 10 line programm -- beginner quest <mischief@velma.motion.net>
Re: print using () functions and lists (Tad McClellan)
Re: problem with setuid script <mischief@velma.motion.net>
Problem with unsubscribe script. I'l take it from the b <fabianos@telia.com>
Question! <simon@nospam.simonwebdesign.com>
Re: Secret planned perl feature revealed <mischief@velma.motion.net>
Re: sendmail problem <chris@spagnet.com>
use strict; <todd@mrnoitall.com>
WIN32:CGI ActiveState(623) with IIS4.0 HTML extra outpu <mike.mcleod@bt.com>
{OT] Re: Guidance on printed output <mjcarman@home.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 2 Mar 2001 16:28:56 +0100
From: "D.J. Poot" <djpoot@kabelfoon.nl>
Subject: Perl unpack() function? How to use?
Message-Id: <97oe2s$c5a$1@news.kabelfoon.nl>
Hello there,
Suppose that I would want to send the user to an url (I do, actually. :) ).
I would do it like so:
---Example---
#!/usr/local/bin/perl
print "Location: newlocation.pl\n\n";
---Example---
Which works fine. Now, however, I would also like to be able to send the
user to an URL that looks like this:
newlocation.pl?menu=[Something that needs to be encoded]&type=[Something
that needs to be encoded]
Here, however, I run into trouble. See, the URL location has to be encoded,
of course. Although the decoding process is not too hard for me (see below)
---Decoding process---
$link = $ENV{'QUERY_STRING'};
@pairs = split(/&/, $link);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/<!--(.|\n)*-->//g;
$FORM{$name} = $value;
}
---Decoding process---
, turning this process around seems to be a huge mountain I have to move. I
have tried the exact same format, but using the function unpack(), as this
should have solved it, and it doesn't. Therefore, I would like to turn to
you for help with this question. How can I turn normal PERL variables into
URL-transmittable ones?
Thanks in advance,
Dominique
------------------------------
Date: Fri, 02 Mar 2001 16:07:17 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: Perl unpack() function? How to use?
Message-Id: <slrn99vh92.7r5.rgarciasuarez@rafael.kazibao.net>
D.J. Poot wrote in comp.lang.perl.misc:
>
> Suppose that I would want to send the user to an url (I do, actually. :) ).
> I would do it like so:
>
> ---Example---
> #!/usr/local/bin/perl
> print "Location: newlocation.pl\n\n";
> ---Example---
You should provide absolute URLs, just to be safe :
print "Location: http://$ENV{HTTP_HOST}/directory/newlocation.pl\n\n";
Quoting the CGI.pm documentation:
One hint I can offer is that relative links may not work correctly
when you generate a redirection to another document on your site.
This is due to a well-intentioned optimization that some servers
use. The solution to this is to use the full URL (including the
http: part) of the document you are redirecting to.
> Which works fine. Now, however, I would also like to be able to send the
> user to an URL that looks like this:
> newlocation.pl?menu=[Something that needs to be encoded]&type=[Something
> that needs to be encoded]
Use the URI::Escape module from CPAN.
> Here, however, I run into trouble. See, the URL location has to be encoded,
> of course. Although the decoding process is not too hard for me (see below)
>
> ---Decoding process---
> $link = $ENV{'QUERY_STRING'};
> @pairs = split(/&/, $link);
[..etc...]
There are a bunch of modules that do that decoding very well. CGI.pm is
the most common (and it's standard). It can also read POST-submitted
variables. There are lighter variants on CPAN if you want.
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
------------------------------
Date: 2 Mar 2001 16:12:29 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Perl unpack() function? How to use?
Message-Id: <97ogpd$4gs$4@mamenchi.zrz.TU-Berlin.DE>
According to D.J. Poot <djpoot@kabelfoon.nl>:
> Hello there,
>
> Suppose that I would want to send the user to an url (I do, actually. :) ).
> I would do it like so:
>
> ---Example---
> #!/usr/local/bin/perl
> print "Location: newlocation.pl\n\n";
> ---Example---
>
> Which works fine. Now, however, I would also like to be able to send the
> user to an URL that looks like this:
> newlocation.pl?menu=[Something that needs to be encoded]&type=[Something
> that needs to be encoded]
>
> Here, however, I run into trouble. See, the URL location has to be encoded,
> of course. Although the decoding process is not too hard for me (see below)
[code snipped]
> , turning this process around seems to be a huge mountain I have to move. I
> have tried the exact same format, but using the function unpack(), as this
> should have solved it, and it doesn't. Therefore, I would like to turn to
> you for help with this question. How can I turn normal PERL variables into
> URL-transmittable ones?
The answer is URI::Escape from CPAN. This is exactly what it does.
Except, of course, it doesn't turn "normal PERL variables" into anything
else. I turns Perl (note spelling) strings, which are arbitrary
sequences of characters, into URL-transmittable ones, but that's what
you want.
Anno
------------------------------
Date: Fri, 2 Mar 2001 17:41:53 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Perl unpack() function? How to use?
Message-Id: <Pine.LNX.4.30.0103021721490.10676-100000@lxplus003.cern.ch>
On Fri, 2 Mar 2001, Rafael Garcia-Suarez wrote:
> > print "Location: newlocation.pl\n\n";
> You should provide absolute URLs, just to be safe :
Agreed.
> print "Location: http://$ENV{HTTP_HOST}/directory/newlocation.pl\n\n";
>
> Quoting the CGI.pm documentation:
But the above isn't invoking CGI.pm! so the CGI.pm documentation
isn't directly relevant to this argument.
> One hint I can offer is that relative links may not work correctly
> when you generate a redirection to another document on your site.
The CGI specification contains two distinctly different forms of the
Location: CGI response - a fully-specified URL (which is documented to
perform an external redirection transaction), and an absolute URLpath
(which the server is mandated to resolve internally). Neither of them
is a relative link.
So there should be no need for such a "hint": the programmer should be
told to send a valid CGI response and only a valid CGI response.
Neither Perl nor CGI.pm have anything to do with this, at least not
directly.
One might suppose that the CGI.pm module _could_ make it its business
to allow the programmer to specify a relative link , and to resolve it
into a form that would be valid as a CGI response. But there's no
reason that the author _has_ to support that, and it appears that he
doesn't. I don't know why the author doesn't simply come right out
and say that CGI.pm at this point doesn't support relative URLs,
period.
> This is due to a well-intentioned optimization that some servers
> use.
I never did agree with that assertion. The CGI specification mandates
the form of the CGI response, and mandates the processing which the
server has to perform on it. It contains no latitude for
optimisation. A relative URL isn't part of that specification, and
thus mustn't be used.
So if there's any reason for this stricture on CGI.pm, then the cause
would either have to lie in CGI.pm itself, or else in a buggy server
implementation, or else in a misunderstanding of what it is legal to
include in a Location: CGI response. IMHO, of course.
> The solution to this is to use the full URL (including the
> http: part) of the document you are redirecting to.
The conclusion, however, is not in dispute. It's the supporting
detail that I'm having problems with.
Don't get me wrong: I use CGI.pm, and I recommend its use to others.
But in a few details I have problems with it, or more to the point,
with its documentation, and this is one of them.
------------------------------
Date: Fri, 02 Mar 2001 16:52:06 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: Perl unpack() function? How to use?
Message-Id: <slrn99vjt3.80b.rgarciasuarez@rafael.kazibao.net>
Alan J. Flavell wrote in comp.lang.perl.misc:
>
> Don't get me wrong: I use CGI.pm, and I recommend its use to others.
> But in a few details I have problems with it, or more to the point,
> with its documentation, and this is one of them.
Thanks for clarifications! I never looked much at those points of the
CGI speciification. It appears that you're completely right.
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
------------------------------
Date: Fri, 2 Mar 2001 17:59:22 +0100
From: "D.J. Poot" <djpoot@kabelfoon.nl>
Subject: Re: Perl unpack() function? How to use?
Message-Id: <97ojc5$htl$1@news.kabelfoon.nl>
[I mailed this to Mr. Anno Siegel first, E-mail follows]
Hello,
Forgive my poor description at the end of my message, and what you described
is indeed what I wanted to do. However, this is my next problem:
How could I use this URI::Escape from CPAN you are talking about? I am
currently using virtualave.net (a free provider which runs CGI scripts too),
so how could I use this in my script, then? I have never used anything like
this.
Thanks in advance,
Dominique
"Anno Siegel" <anno4000@lublin.zrz.tu-berlin.de> schreef in bericht
news:97ogpd$4gs$4@mamenchi.zrz.TU-Berlin.DE...
> According to D.J. Poot <djpoot@kabelfoon.nl>:
> > Hello there,
> >
> > Suppose that I would want to send the user to an url (I do, actually.
) ).
> > I would do it like so:
> >
> > ---Example---
> > #!/usr/local/bin/perl
> > print "Location: newlocation.pl\n\n";
> > ---Example---
> >
> > Which works fine. Now, however, I would also like to be able to send the
> > user to an URL that looks like this:
> > newlocation.pl?menu=[Something that needs to be encoded]&type=[Something
> > that needs to be encoded]
> >
> > Here, however, I run into trouble. See, the URL location has to be
encoded,
> > of course. Although the decoding process is not too hard for me (see
below)
>
> [code snipped]
>
> > , turning this process around seems to be a huge mountain I have to
move. I
> > have tried the exact same format, but using the function unpack(), as
this
> > should have solved it, and it doesn't. Therefore, I would like to turn
to
> > you for help with this question. How can I turn normal PERL variables
into
> > URL-transmittable ones?
>
> The answer is URI::Escape from CPAN. This is exactly what it does.
>
> Except, of course, it doesn't turn "normal PERL variables" into anything
> else. I turns Perl (note spelling) strings, which are arbitrary
> sequences of characters, into URL-transmittable ones, but that's what
> you want.
>
> Anno
------------------------------
Date: 2 Mar 2001 17:15:34 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Please help - Find files recursively by File::Find
Message-Id: <97okfm$bpf$1@mamenchi.zrz.TU-Berlin.DE>
According to Tad McClellan <tadmc@augustmail.com>:
> Luke <cub@lukebsd.com> wrote:
> >I'm trying to find all the .log files recursively within a big directory.
> >I already got it working with this:
> >
> >use File::Find;
>
> >Now I'd like to list only the .log files that are 4 days old. How do I
> >go for doing this?
>
>
> $names{$File::Find::name}++ if /\.log$/ and int(-M) == 4;
I know this is what the OP asked for, but in the spirit of DWIM
I'd like to offer
$names{$File::Find::name}++ if /\.log$/ and -M >= 4;
Actually, at first I overlooked the int() you put around -M and
thought, ah... he's teaching him a lesson :)
Anno
------------------------------
Date: Fri, 02 Mar 2001 16:24:30 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Please Help with 10 line programm -- beginner questions
Message-Id: <t9vi9uer24nj7a@corp.supernews.com>
John Joseph Trammell <trammell@bayazid.hypersloth.net> wrote:
> On Mon, 26 Feb 2001 16:38:25 -0500, Shane McDaniel <shanem@ll.mit.edu> wrote:
>> Cool. It's points like these that I like to tell people that "Every
>> programming language will let you shoot yourself in the foot, however
>> with perl you're using an automatic."
> And what good is a gun that won't let you shoot yourself
> in the foot if you want to, anyhow? :-)
Exactly. If I'm building a gun, I want it to shoot where aimed. It's
up to the wielder to aim it.
On the other hand, it might be nice to have a gun that identifies
friend or foe, and has multiple levels of safety - one that doesn't
let it fire, and one that lets it fire only at foes, one that lets
it fire at anything that's not friend, and one that lets it fire
at anything, including friendly targets.
I think Perl has a safety mechanism much like the one above. With
the same section of code, one can get it not to be run with lots
of complaints, to not be run with moderate complaints, to not be
run with relatively few complaints, to be run but complain, to be
run without complaint, and to be run without as much as a grumble.
Chris
--
Christopher E. Stith
You can never entirely stop being what you once were. That's
why it's important to be the right person today, and not put
it off till tomorrow. -- Larry Wall, 3rd State of the Onion
------------------------------
Date: Fri, 2 Mar 2001 09:16:49 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: print using () functions and lists
Message-Id: <slrn99vaqg.oij.tadmc@tadmc26.august.net>
Alun Moon <alun.moon@unn.ac.uk> wrote:
>I had a little discussion with a colleague recently concerning
>the use of
> print("hello world\n");
>rather than
> print "hello world\n";
>
>He was intending to use the former () to teach students hew to perl.
That is "safer" in that it protects against the few times that
Perl's "If it looks like a function, it is a function" rule
can bite you.
The rule is described in the "Terms and List Operators (Leftward)"
section near the top of perlop.pod.
>I felt that the later was better, as seen in the perldocs and the
>Camel book(s) (Leaning Perl, Programming Perl).
It is better, except for when you run afoul of the abovementioned rule.
Punctuation makes things harder for humans to read, so leaving it
out is generally a Good Thing. But sometimes you cannot leave
them out.
>I was concerned that there were side effects of using () that
>were bad habits to teach students.
The only "bad" side effect (that I can see) of using parens is
that it may be harder for a human to read.
The only "bad" side effect (that I can see) of omitting parens is
that it may not execute as intended.
I think omitting parens should be taught, along with a warning
of how to recognize when parens are required.
>Having read through the docs perlfunc and Programming Perl, I'm a little
>unclear.
The usual confusion is due to Perl giving the programmer
a choice of parenthesizing or not.
When a function call "looks like" a function call, then perl thinks
"this is the kind of Perl programmer who likes to put parens around
arg lists". The parser's job (identify the bounds of the arg list)
is then very easy, it just goes until it finds the matching close
paren.
When a function call does not "look like" a function call, then
perl thinks "this is the kind of Perl programmer who likes to omit
parens around arg lists". The parser's job is harder, it resorts
to precedence to help decide where the arg list ends, as described
in perlop. Sometimes perl's "end of arg list" and the programmer's
intended "end of arg list" do not match up, as in Anno's followup.
>The section on Terms and List Operators (pg 77)
Errr, you should have mentioned what edition of the Camel you
are quoting. Looks like the second edition.
>implies that there
>are effects of using () in the print, making it a function rather
>that a list operator.
There is no distinction between a "function" and a "list operator".
The terms are interchangeable. There is no difference in behavior
between using parens and omitting parens. The operator may see
a different argument list between using and omitting parens though.
>But in the back (pg 548) it says ``if in
>doubt perenthisise''.
>
>I'm farly convinced I was right to suggest teaching print without
>() was right. Was I?
Yes, if you also warn about when to _not_ leave them out.
>What exactly is the effect of using () on not in print (and other
>operators)?
It affects the bounds of the arg list.
It is not specific to print() at all. It applies to all operators,
though print() is often where you see it discussed.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 02 Mar 2001 18:59:41 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: problem with setuid script
Message-Id: <t9vrctq2ia3ca7@corp.supernews.com>
Ray Rizzuto <ray.rizzuto@ulticom.com> wrote:
> Hi!
> I am running a perl script from a korn shell setuid script, and getting these errors:
> Insecure dependency in require while running setuid at reformatCr line 13.
> BEGIN failed--compilation aborted at reformatCr line 13.
> Any help would be appreciated! I've had no luck searching the FAQ, or the camel book.
Why is it that `RTFM' isn't spelled `STFM'? Because `search' starts with an `s' and
`read' starts with an `r'. I wouldn't expect someone to read all the available docs
every time he or she has a problem, but it would be nice if people would read a
section now and then to really learn it.
If, however, you had known to search the Camel for the string `suid' then searched
the Camel for the word `taint', then you _might_ (I'm not sure) have been on to
something.
You could always RTFM called `perlsec', which has to do with Perl security, and in the
second paragraph or so found out that all setuid or setgid programs are run in taint
mode. You then could read the section on taint mode in that same document.
Chris
--
Christopher E. Stith
For the pleasure of others, please adhere to the following
rules when visiting your park:
No swimming. No fishing. No flying kites. No frisbees.
No audio equipment. Stay off grass. No pets. No running.
------------------------------
Date: Fri, 02 Mar 2001 15:02:07 GMT
From: "Fabian" <fabianos@telia.com>
Subject: Problem with unsubscribe script. I'l take it from the begining.
Message-Id: <PBOn6.21240$AH6.2940086@newsc.telia.net>
This script should delete e-mail adresses from my e-mail list, using e-mail
data from form.
I'l get no server error messages but no submitted e-mail addresses deletes.
The form is named remove.htm and looks like this:
<form action="../cgi-markisspecialisten/remove.pl" method="POST">
<p>Email Address: <input type="text" size="20" name="address">
</p>
<input type="submit" value="Skicka">
</form>
The script is named remove.pl and looks like this:
#!/usr/bin/perl -w
read(STDIN, $email, $ENV{'CONTENT_LENGTH'}); ## I guess that this line reads
the e-mail address from the form *
use strict;
use Fcntl qw(:flock);
print "Content-type: text/html\n\n";
my $file = '/home/markisspecialisten/www/guestmail.htm';
my $lockfile = "$file.lock";
open LOCKFILE, ">>$lockfile" or die "cannot open lock file $lockfile: $!";
flock(LOCKFILE, LOCK_EX) or die "cannot lock file exclusively: $!";
open FILE, "<$file" or die "cannot open $file for input: $!";
my @emailfile = <FILE>;
close (FILE) or die "cannot close message file: $!";
open FILE, ">$file" or die "cannot open $file for output: $!";
my $email = 'someone@somewhere'; ## * So, wath is this?
my $line;
foreach $line (@emailfile)
{
if ($line !~ /^\Q$email/o) ## * And search for it here
{
print FILE $line; ## * And delete it here
}
}
close (FILE) or die "cannot close final message file: $!";
close (LOCKFILE) or die "cannot close lock file: $!";
# (end)
The e-mail list is named mail.htm and looks like this:
<!--begin-->
someone@somewhere.com<br>
someone2@somewhere.com<br>
someone3@somewhere.com<br>
someone4@somewhere.com<br>
------------------------------
Date: Fri, 2 Mar 2001 13:59:12 -0500
From: "Simon" <simon@nospam.simonwebdesign.com>
Subject: Question!
Message-Id: <t9vrdu74ln3haa@corp.supernews.co.uk>
Is it possible to add the .html extension to the script mapping options in
Perl/Apache so it is processed in the same manner as Perl scripts.
The reason for asking is I have noticed a couple of web sites that post data
form a form to an HTML page like so: (this comes from
https://www.ihavemoved.com/register.html)
<FORM ACTION="/register.html" METHOD="POST">
The register.html page validates the document and then adds your info to a
database and it does not pass the info in data in the URL. I believe they
are running Apache on Solaris.
Thanks in anticipation
Simon
http://simonwebdesign.com
------------------------------
Date: Fri, 02 Mar 2001 18:41:39 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Secret planned perl feature revealed
Message-Id: <t9vqb3ibt98gbd@corp.supernews.com>
cdh <cdh@ala.net> wrote:
> perl -e 'print "Perl, please automatically write the program I am thinking of right now!\n"; $perl = sub { print "Yes Master, here
> is what I need...\n" }; do &$perl()'
> Yes, I know there's an error... therein lies the funny part;)
> Later,
> Chris Hickman
> P.S. this works on 5.6.0, I don't know if it's present in other versions.
It's not in 5.005_03 but it is funny when run under 5.6.0!
Notice, though, that using 'do' to call a subroutine is deprecated according
to perlfunc in both 5.005_03 and 5.6.0 versions of the docs, and it refers
you to perlsub.
I bet, with my idea I think suported by the 'Null filename' errors below,
that in 5.6.0 attempting to call a subroutine with 'do' actually _sometimes_
invokes one of do()'s other semantics - that of compiling a Perl source
file and returning the last value evaluated in that file.
Notice also that if you put the '&$perl();' part inside a block, which is
a totally different meaning of do() according to the docs, you get no error.
Perhaps what needs to be done is a doc update more than a bugfix for the code.
It would seem that calling a subroutine with 'do' is not only deprecated, but
is also of undefined behavior. If this isn't the intent, then there does need
to be a change to the code - unless it's easier to just enforce the deprecation
by not changing the code. It has been deprecated for some time now.
Here are some more boiled-down versions, each with its output:
/usr/local/bin/perl -e '$perl = sub {print}; do &$perl();'
Perl v49.0.1075313024 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub { print }; do &$perl();'
Perl v49.0.0 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub {//}; do &$perl();'
Perl v49.0.0 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub { // }; do &$perl;'
Perl v49.0.2 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub {m//}; do &$perl();'
Perl v49.0.2 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub {}; do &$perl();'
Null filename used at -e line 1.
/usr/local/bin/perl -e '$perl = sub {for(@foo){}}; do &$perl();'
Null filename used at -e line 1.
/usr/local/bin/perl -e '$perl = sub {while(0){}}; do &$perl();'
Null filename used at -e line 1.
/usr/local/bin/perl -e '$perl = sub {!$foo}; do &$perl();'
Perl v49.0.0 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub { printf }; do &$perl();'
Perl v49.0.1075313024 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -we '$perl = sub { print; }; do &{$perl}();'
Use of uninitialized value in print at -e line 1.
Perl v49.0.135134720 required--this is only v5.6.0, stopped at -e line 1.
/usr/local/bin/perl -e '$perl = sub { print; }; do &{$perl}();'
Perl v49.0.0 required--this is only v5.6.0, stopped at -e line 1.
Notice how using warnings changes how the supposed version requirement is
stated.
Chris
--
Christopher E. Stith
Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental. -- nobull, clp.misc
------------------------------
Date: Fri, 2 Mar 2001 11:45:53 -0500
From: Chris Barnabo <chris@spagnet.com>
Subject: Re: sendmail problem
Message-Id: <MPG.15099850c540fcec9896ba@news.supernews.com>
On Fri, 02 Mar 2001 01:56:17 GMT, Dave Brondsema <brondsema@my-deja.com>
said ...
> I have a simple perl CGI program to send out newsletters. I haven't really
> used sendmail before and I'm having problems.
Dave, another option you might consider is using a module to handle the
mail so you don't have to worry about piping, unfamiliar interfaces, etc.
I'm using the Mail::Sendmail module which, despite the name, does *not* use
sendmail to do it's work - it's implemented entirely within Perl and sends
your note directly via sockets to the smtp server. There are other modules
on CPAN that accomplish the same task in varying ways, depending on your
requirements.
I decided to use Mail::Sendmail because although my production environment
(Linux) has sendmail, my test environment (Win95 + Apache) doesn't. I
wanted something that would work seamlessly in both environments with a
minimum of effort.
------------------------------
Date: Fri, 02 Mar 2001 11:56:57 -0700
From: Todd Anderson <todd@mrnoitall.com>
Subject: use strict;
Message-Id: <3A9FECF6.A098184@mrnoitall.com>
I am trying to implement "use strict;
My script is crippled when this is inserted asis. I was told that "use
strict;" can't be used when requiring other scripts.
Is it possible to 'use srict;' after you have required the other
scripts?
Thanks for your remarks...
------------------------------
Date: Fri, 2 Mar 2001 16:39:01 -0000
From: "mike mcleod" <mike.mcleod@bt.com>
Subject: WIN32:CGI ActiveState(623) with IIS4.0 HTML extra output
Message-Id: <97oifc$2oq$1@pheidippides.axion.bt.co.uk>
I have a simple imbeded browser that only accepts HTML/XML or text.
When I try to use a CGI Perl script and try to output a simple message like:
use CGI qw(-no_xhtml :standard);
print header;
print start_html('A Simple Example'),
print "a simple message";
My browser shows all of the html:
1<!DOCTYPE html PUBLIC"-//W3C//DTD HTML 1.0......
Is there a way to just output vanilla html?
Please reply directly to me.
Usual disclaimer.....bla
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike McLeod
01473 606251 Fax 606782
mike.mcleod@bt.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Fri, 02 Mar 2001 08:08:29 -0600
From: Michael Carman <mjcarman@home.com>
Subject: {OT] Re: Guidance on printed output
Message-Id: <3A9FA95D.7D57A4FD@home.com>
"Alan J. Flavell" wrote:
>
> On Thu, 1 Mar 2001, Michael Carman wrote:
>
>>> <P STYLE="page-break-after: always">
>>
>> This has nothing to do with Perl.
>
> Right, so the poster should seek accurate information in a more
> appropriate place.
>
>> It's an HTML thing,
>
> No it isn't. The working parts are CSS, merely enclosed in HTML.
Ah, that makes more sense. I guess you can tell how long it's been since
I've done any significant web development. :)
-mjc
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 398
**************************************
