[9825] in Perl-Users-Digest
Perl-Users Digest, Issue: 3418 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 11 15:07:47 1998
Date: Tue, 11 Aug 98 12:00:27 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 11 Aug 1998 Volume: 8 Number: 3418
Today's topics:
Re: Access, ODBC and Linux <thaynes@openlinksw.co.uk>
Re: attach file to email <JKRY3025@comenius.ms.mff.cuni.cz>
Re: comp.lang.perl.announce redux birgitt@my-dejanews.com
Re: Date and Time huntersean@hotmail.com
Re: Date and Time (Mike Stok)
Re: dates in excess of 2037 (A Problem???) lvirden@cas.org
Re: dates in excess of 2037 (A Problem???) (Craig Berry)
Re: dates in excess of 2037 (A Problem???) (Larry Rosler)
Re: dates in excess of 2037 (A Problem???) <nguyend7@egr.msu.edu>
Re: dates in excess of 2037 (A Problem???) (Larry Rosler)
Efficient number crunching <matthies@fsinfo.cs.uni-sb.de>
Re: Efficient number crunching (Greg Bacon)
Re: Efficient number crunching <zenin@bawdycaste.org>
Evaluating empty fields/variables? <rosso@rsn.hp.com>
Re: Evaluating empty fields/variables? (Matt Knecht)
Re: Evaluating empty fields/variables? (Craig Berry)
Re: File::Copy <rootbeer@teleport.com>
Re: Frames (Steve Linberg)
Re: help parsing mail file (Abigail)
HTML & Javascript Tests <mike.russiello@tekmetrics.com>
Re: HTML & Javascript Tests (Chris Nandor)
Re: HTML & Javascript Tests <rootbeer@teleport.com>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 Aug 1998 15:45:03 GMT
From: Tim Haynes <thaynes@openlinksw.co.uk>
Subject: Re: Access, ODBC and Linux
Message-Id: <6qpotv$dut$1@nnrp1.dejanews.com>
In article <6qomta$3pu$1@nnrp1.dejanews.com>,
neillunn@ozemail.com.au wrote:
> In article <35cd9a30.3639593@news.tuwien.ac.at>,
> Reibenschuh@Interdrive.com wrote:
> > On 7 Aug 1998 17:28:21 GMT, scott@softbase.com wrote:
> > >Stiphane Dupille (sdupille@yahoo.com) wrote:
> > >> I try to access Access database on WinNT from a linux
> > >> workstation.
> > >Isn't going to happen. Access is not a database like Oracle and DB2
> > >which can be accessed over a network. Access is a single-machine
> > >small-time database not meant for client/server applications. (That
> > >doesn't stop people from *thinking* Access is capable of doing more
> > >than it does, but anyone who tries to use it for anything other than a
> > >mailing list will quickly discover the truth!)
> Paranoia reigns suppreme yet again. Sure, Access isn't a real database, but
> unfortunately a lot of people out there are using it. Mostly because they
> really aren;t that comfortable with a real database (kind of scary really!).
Too true :)
> First off you can go to OpenLink softawre http://www.openlinksw.com where,
> there are multi-tier driver setup's available for free evaluation download.
> There is a ODBC driver for Access databases (iODBC is bundled) but this has
> been aimed at accessing a local file (I think!).
> Funny enough Openlink will suport say ODBC to an SQL server on NT by using an
> agaent running on NT to control the local access. I don't think that's been
> done here, but you can always ask openlink.
Indeed, you're absolutely right: with our Multi-Tier architecture, you have a
generic client (choose the linux one) and a request broker and database agent
(choose NT and use the generic ODBC agent). Once you have a System DSN over
the Access driver to your database, you can point Linux at it as stated in a
previous posting of mine.
> Choices: Failing a civilized response from OpenLink, you can always
*cough* :)
> i.) Replicate the DB on linux.
How, if you cannot get to it from Linux?
> ii.) Use some commecial NFS package or Samba to get access to the NT volume.
How is this useful, if you cannot read .mdb files on Linux directly?
HTH
~Tim
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Tue, 11 Aug 1998 20:20:15 -0700
From: Jan Krynicky <JKRY3025@comenius.ms.mff.cuni.cz>
To: c.clark@student.unsw.edu.au
Subject: Re: attach file to email
Message-Id: <35D109EF.AB6@comenius.ms.mff.cuni.cz>
c.clark@student.unsw.edu.au wrote:
>
> Hi,
>
> Does anyone have some sample script that allows you to attach a file
> to email? (I'm wanting to create a sort of virtual flowers type
> thing, but where the image is generated and sent to the person).
>
> Ta,
>
> Chris.
1. Mail::Sender http://jenda.krynicky.cz
socket() based, no external program required
2. some versions of sendmail and the newest blat.exe have
some options for attaching files. See their man pages/documentation.
3. I believe that there are modules that will help you to
properly encode the parts and generate the correct headers.
You may then pipe the result to sendmail.
Go to see CPAN - http://www.perl.com/CPAN/
HTH, Jenda
------------------------------
Date: Tue, 11 Aug 1998 16:50:01 GMT
From: birgitt@my-dejanews.com
Subject: Re: comp.lang.perl.announce redux
Message-Id: <6qpsnp$jf7$1@nnrp1.dejanews.com>
In article <86r9yonyrk.fsf@scooter.cis.ohio-state.edu>,
Matt Curtin <cmcurtin@interhack.net> wrote:
> Randal Schwartz <merlyn@stonehenge.com> writes:
>
> > I write back (in English) to say "hey, CLPA gets
> > worldwide distribution -- could you rewrite that in English so more
> > people can read it?" and I either get a new English posting, or
> > nothing.
>
> I'm not sure this is the Right Thing(tm) to do. Here's why.
[snip]
>
> So what if someone can read enough English to read the newsgroup, but
> not enough to be confident enough to post in English?
Why not a small private mailing-list to help out Mr. Schwartz ?
He could post these foreign language announcements he might get
to the mailing list of a small group of Perl knowledgable persons
who would be willing to translate them for him. I think if he
would ask who can translate from which language into English he
would get quite a response.
Birgitt Funk
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Tue, 11 Aug 1998 16:54:09 GMT
From: huntersean@hotmail.com
Subject: Re: Date and Time
Message-Id: <6qpsvh$jrf$1@nnrp1.dejanews.com>
In article <6qpf9c$1aj@news-central.tiac.net>,
mike@stok.co.uk (Mike Stok) wrote:
> In article <6qp6q3$mf7$1@nnrp1.dejanews.com>, <huntersean@hotmail.com> wrote:
>
> >You probably want something like this:
> >
> >my @month = qw(JAN, FEB, MAR, APR, MAY, JUN,
> > JUL, AUG, SEP, OCT, NOV, DEC);
>
> Note that this will make @month contain elements like 'JAN,' - using the
> -w flag would pick this up and warn you with a message like:
>
> Possible attempt to separate words with commas at ...
>
> Of course sometimes a trailing comma is intentional, but given the later
> use of %3.3s as a format specifier for outputting the month I would guess
> that in this case it isn't.
>
> Mike
> --
EEEK! You're right of course. I was actually using perl -w and use strict,
but didn't get any warning. Perhaps my version(5.002 for solaris) is too old?
Sean H
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: 11 Aug 1998 17:17:43 GMT
From: mike@stok.co.uk (Mike Stok)
Subject: Re: Date and Time
Message-Id: <6qpubn$ba8@news-central.tiac.net>
In article <6qpsvh$jrf$1@nnrp1.dejanews.com>, <huntersean@hotmail.com> wrote:
>EEEK! You're right of course. I was actually using perl -w and use strict,
>but didn't get any warning. Perhaps my version(5.002 for solaris) is too old?
5.004_04 or 5.004_05 when it arrives might be the best choices for a
stable pler for now. There are versions of 5.005 about, but my personal
preference is to wait until things have been stable for a couple of months
before upgrading a "live" system. There are always trade-offs and what
makes sense to me may not make sense to you.
Mike
--
mike@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ | PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.tiac.net/users/stok/ | 65 F3 3F 1D 27 22 B7 41
stok@colltech.com | Collective Technologies (work)
------------------------------
Date: 11 Aug 1998 15:28:41 GMT
From: lvirden@cas.org
Subject: Re: dates in excess of 2037 (A Problem???)
Message-Id: <6qpnv9$9t3$1@srv38s4u.cas.org>
Courtesy Cc to the poster
According to Dominic Tootell <tootedom@mlch.ml.com>:
:I have very interesting problem for you. I need to calculate the number
:of days between two dates (in perl). OK.. use the localtime function
:supply a date with the year 2028. The function does not work, The
I am assuming you mean 2038 or later here, as 2028 should be fine.
:there must be quite a few important applications that use this library
:which will fail when using a date in excess of 2037.
I suspect this is going to become a real problem for programs calculating
30+ year mortgages in a short amount of time.
:This is just not a problem limited to perl, perl use the unix epoch date
:to get the number of seconds since 1970, so does this then mean quite a
:few other applications will have a problem?
There apparently are very few important applications which project out
that far. All the talk I see on newsgroups indicate folk expect that
'eventually' someone somewhere will increase the width of time_t,
resolving the problem.
But then, for years _I_ heard folk saying that eventually something would
need to be done about those pesky 2 digit years....
:This is a very important problem that I need solving. I have kind of a
:solution, but it is just a patch.
I myself recommend that you consider creating a Perl Package (perhaps
called something like DateTime::BigTime ...) that casts the time_t sized
variable into a variable that is twice as big, then provide a series of
functions to manipulate this new data type.
If written carefully, perhaps it will be able to continue to be used
once OS vendors get off their duffs and solve the problem officially.
--
<URL:mailto:lvirden@cas.org> Quote: In heaven, there is no panic,
<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
------------------------------
Date: 11 Aug 1998 16:51:34 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: dates in excess of 2037 (A Problem???)
Message-Id: <6qpsqm$ic6$3@marina.cinenet.net>
Dominic Tootell (tootedom@mlch.ml.com) wrote:
: Hi everyone... how are you doing??
Not bad at all...good questions in clpm this morning. :)
: I have very interesting problem for you. I need to calculate the number
: of days between two dates (in perl). OK.. use the localtime function
: supplied with the perl standard library to get the number of seconds
: since 1 January 1970 for the first date, then the number of second for
: the second date. Minus the two and then perform the calculation
: (((Remaining seconds/60)/60)/24).
:
: Ok fine that works, but the problem arises when you
: supply a date with the year 2028. The function does not work, The
^ Should be '3', right?
: integer width cannot hold the seconds value, since 2038.
Or, rather, cannot hold the number of seconds between 1970 and 2038. Yes,
this is the well-known 'Y2038 problem,' which unlike the Y2K problem is
not caused by poor coding practices, but rather by a fundamental
limitation of an underlying data type deep in the guts of Unix (and many
OSs and languages influenced by Unix). Specifically, the type time_t is
a 32-bit signed integer count of seconds since January 1 1970. (Why they
made it signed is beyond me; were it unsigned, we'd have a Y2126 problem
instead.)
: This is quite a problem as I can see a few people using this to
: calculate the days between two dates which uses this function, and
: there must be quite a few important applications that use this library
: which will fail when using a date in excess of 2037.
In the current state of the world, you have to use special time-related
functions (of your own, or obtained from elsewhere) to do 2038+
calculations. I presume that we'll see a move to a 64-bit time_t sometime
in the next decade, though it's going to be a painful conversion given the
amount of software out their using 32 bits to hold time_t.
: This is just not a problem limited to perl, perl use the unix epoch date
: to get the number of seconds since 1970, so does this then mean quite a
: few other applications will have a problem?
Yes, in all likelihood many more than have Y2K problems. After all,
everybody has known and admitted that the kinds of data-storage shortcuts
that lead to Y2K errors are a Bad Thing for many years now, so good
developers have avoided them. Conversely, storing time values in the type
time_t is the officially 'right', sanctioned way to do things.
: An ideal solution to the problem would be:-
:
: Get the number of seconds from 1970 until an end date in 2037, then
: specify that end date as the start of the next calculation, so that you
: can get the number of seconds since that date
:
: eg. date 1/12/2040.
:
: get the number of seconds since 1/1/1970 for the date 1/12/2037. Then
: get the number of seconds since 1/12/2037 to the final date 1/12/2040.
:
: This would be perfect,but is there anyway of specifying this.
Personally, I'd prefer just going to 64-bit ints for the computation if
you're rolling your own code. And in this circumstance, I'd also move the
epoch back (to e.g. 1800 or the like) to keep all dates I might ever want
to deal with positive.
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: Tue, 11 Aug 1998 10:52:42 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: dates in excess of 2037 (A Problem???)
Message-Id: <MPG.103a24c4ca8cb97989761@nntp.hpl.hp.com>
[Posted to comp.lang.perl.misc and a copy mailed.]
In article <6qpsqm$ic6$3@marina.cinenet.net> on 11 Aug 1998 16:51:34 GMT,
Craig Berry <cberry@cinenet.net> says...
...
> Or, rather, cannot hold the number of seconds between 1970 and 2038. Yes,
> this is the well-known 'Y2038 problem,' which unlike the Y2K problem is
> not caused by poor coding practices, but rather by a fundamental
> limitation of an underlying data type deep in the guts of Unix (and many
> OSs and languages influenced by Unix). Specifically, the type time_t is
> a 32-bit signed integer count of seconds since January 1 1970. (Why they
> made it signed is beyond me; were it unsigned, we'd have a Y2126 problem
> instead.)
Y2106. But who's counting? :-)
The signedness of time_t isn't the problem. One could (in application
coding, for example) simply deal with it as unsigned, allowing one to
count only forward from the Unix Epoch. The problem is that most date
computations involve *intervals* (the difference between two times), and
the difference is inherently signed.
So simple arithmetic introduces an ambiguity in calculating the
difference between two times that differ by more than ~68 years. This
can be resolved using expressions that determine which of the two
operands to the subtraction is larger than the other (each considered as
unsigned), and adjusting the difference accordingly. As the result has
32 bits *and* a sign, Perl cannot deal with it as an integer, but string
representation would be workable.
--
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 11 Aug 1998 18:00:37 GMT
From: Dan Nguyen <nguyend7@egr.msu.edu>
Subject: Re: dates in excess of 2037 (A Problem???)
Message-Id: <6qq0s5$aht$1@msunews.cl.msu.edu>
Larry Rosler <lr@hpl.hp.com> wrote:
: In article <6qpsqm$ic6$3@marina.cinenet.net> on 11 Aug 1998 16:51:34 GMT,
: Craig Berry <cberry@cinenet.net> says...
: The signedness of time_t isn't the problem.
What Craig was saying is the because of the signness of time_t, it
shortens the life span of the current system. Because negtive values
are used for dates preceeding the Unix Epoch. True an app could just
use an unsigned time_t, but then a date the app kept track of and that
of the OS would be different.
If time_t were moved to a 64-bit integer we would then have a
Y292277267641 bug that will eventually need to be fixed as well.
But I'll rather wait until then to fix it.
--
Dan Nguyen | There is only one happiness in
nguyend7@msu.edu | life, to love and be loved.
http://www.cse.msu.edu/~nguyend7 | -George Sand
------------------------------
Date: Tue, 11 Aug 1998 11:45:16 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: dates in excess of 2037 (A Problem???)
Message-Id: <MPG.103a31166d948405989763@nntp.hpl.hp.com>
[Posted to comp.lang.perl.misc and a copy mailed.]
In article <6qq0s5$aht$1@msunews.cl.msu.edu> on 11 Aug 1998 18:00:37 GMT,
Dan Nguyen <nguyend7@egr.msu.edu> says...
> Larry Rosler <lr@hpl.hp.com> wrote:
> : In article <6qpsqm$ic6$3@marina.cinenet.net> on 11 Aug 1998 16:51:34 GMT,
> : Craig Berry <cberry@cinenet.net> says...
>
> : The signedness of time_t isn't the problem.
>
> What Craig was saying is the because of the signness of time_t, it
> shortens the life span of the current system. Because negtive values
> are used for dates preceeding the Unix Epoch. True an app could just
> use an unsigned time_t, but then a date the app kept track of and that
> of the OS would be different.
As you missed my point, let me try again, this time with an example.
Consider a time near the beginning of the scale, signed or unsigned. For
concreteness, let's say unsigned, and let its value be 1 second. Now
consider a time near the end of the scale, with value 0xFFFFFFFE. The
interval between these two times is 0xFFFFFFFD, which we agree is a very
large number. Now consider any two times which are three seconds apart.
The interval between these two times is 3 or 0XFFFFFFFFD, which is a
small number. The problem is roll-over in conventional 32-bit
arithmetic, not in the signedness of time_t.
> If time_t were moved to a 64-bit integer we would then have a
> Y292277267641 bug that will eventually need to be fixed as well.
> But I'll rather wait until then to fix it.
Provided integer representations and arithmetic were also done using 64-
bit quantities. What plans are there for Perl to switch to 64-bit
internal integer representations Any Time Soon Now?
--
Larry Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 11 Aug 1998 16:50:27 GMT
From: Niklas Matthies <matthies@fsinfo.cs.uni-sb.de>
Subject: Efficient number crunching
Message-Id: <6qpsoj$m8f$1@hades.rz.uni-sb.de>
Hi there,
I'm calcualting 32-bit CRC checksums of scalars (rather large ones, like
a couple of Kbytes each). (In case you wonder, this is not for detecting
corrupted data, but for use as a hash function, to find out faster whether
there is already an equal file in a large, otherwise unstructured file
repository, when inserting a new one -- if you know a faster-to-calculate
hash function with similar properties, please tell me.)
Ok, here's the implementation:
sub crc32 {
use integer;
my @a = unpack ('C*', $_[0]); # split the scalar to the ordinal values
# of its characters
my $crc = 0xffffffff; # calculate CRC checksum (next line)
foreach (@a) { $crc = $_crc32_tab[($crc ^ $_) & 0xff] ^ ($crc >> 8) }
# @_src32_tab is just a precalculated array of 256 32-bit numbers
return ~$crc;
}
This is pretty the fastest I've come up with, but still rather slow
compared with a C implementation. Any ideas how to speed this up, other
than embedding C (which wouldn't be really worth the hassle for me)?
The following variations are even slower:
sub crc32 {
use integer;
my $crc = 0xffffffff;
for (0..((length $_[0]) - 1)) {
$crc = $_crc32_tab[($crc ^ ord (substr ($_[0], $_, 1))) & 0xff] ^
($crc >> 8);
}
return ~$crc;
}
sub crc32_ {
use integer;
my $crc = 0xffffffff;
$crc = $_crc32_tab[($crc ^ ord $1) & 0xff] ^ ($crc >> 8)
while ($_[0] =~ /\G(.)/g); # yes, I know, but I had to try :)
return ~$crc;
}
-- Niklas
------------------------------
Date: 11 Aug 1998 18:13:45 GMT
From: gbacon@cs.uah.edu (Greg Bacon)
Subject: Re: Efficient number crunching
Message-Id: <6qq1kp$2vb$2@info.uah.edu>
In article <6qpsoj$m8f$1@hades.rz.uni-sb.de>,
Niklas Matthies <matthies@fsinfo.cs.uni-sb.de> writes:
: I'm calcualting 32-bit CRC checksums of scalars (rather large ones, like
: a couple of Kbytes each).
[snip]
: This is pretty the fastest I've come up with, but still rather slow
: compared with a C implementation.
Then use the C implementation that comes with Perl! From the perlfunc
entry on unpack:
In addition, you may prefix a field with a %E<lt>numberE<gt> to
indicate that you want a <number>-bit checksum of the items
instead of the items themselves. Default is a 16-bit checksum. For
example, the following computes the same number as the System V sum
program:
while (<>) {
$checksum += unpack("%16C*", $_);
}
$checksum %= 65536;
Of course, this isn't useful in the general case. If you're interested
in using fast C implementations of common mathematical operations, you
might find PDL useful. Check it out on the CPAN.
Greg
--
As a general rule, don't solve puzzles that open portals to Hell.
-- Ralph Mason
------------------------------
Date: 11 Aug 1998 18:27:43 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Efficient number crunching
Message-Id: <902860687.264652@thrush.omix.com>
Niklas Matthies <matthies@fsinfo.cs.uni-sb.de> wrote:
>snip<
: This is pretty the fastest I've come up with, but still rather slow
: compared with a C implementation. Any ideas how to speed this up, other
: than embedding C (which wouldn't be really worth the hassle for me)?
Have you taken a look at the perlxstut man page? I think you'd
be surprised at just how easy created perl modules in C can
be.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: Tue, 11 Aug 1998 11:38:32 -0500
From: Sara Rosso <rosso@rsn.hp.com>
Subject: Evaluating empty fields/variables?
Message-Id: <35D07388.3E84@rsn.hp.com>
Hello - I am working on a cgi perl script that generates an on-the-fly
html page from form submission data. It is essentially a Project Data
Sheet (PDS) generator. (The problem I have IS a perl problem, not a
cgi-problem, though)
The use of certain input fields will differ from user to user, so I am
trying to recognize an empty field and use a if-else loop to return a
variable full of html if it has data, and return a blank variable if it
is empty.
This is the subroutine that I have so far:
sub makedelivlist {
$delim = ';';
$in{'deliverables'} =~ s/\r\n/$delim/;
if ($in{'deliverables'} != "")
{
@stuff = split(/$delim/, $in{'deliverables'});
$towritedeliv = "<p><font face=\"Arial\" color=\"blue\"><b>Major
Deliverables</b></font></p>\n";
$towritedeliv .= "<ul>\n";
for $i (0 .. $#stuff)
{
$towritedeliv .= "<li>$stuff[$i]\n";
}
$towritedeliv .= "</ul>";
}
else {
$towritedeliv = "";
}
.
I reference this variable in the main routine by this line:
print PDSTEMP $towritedeliv;
So if the $towritedeliv is empty, then it will just print out nothing,
and go on, but otherwise it will include the "Major Deliverables"
section.
*I think my problem may be I am treating the field like number data,
when it's really text...but I don't know how to do that. I have looked
through several FAQ, and an ORA Perl book, but they don't have what I am
looking for.
I would appreciate any input you can give me on this. Thanks in advance.
Sara Rosso
------------------------------
Date: Tue, 11 Aug 1998 17:14:31 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: Re: Evaluating empty fields/variables?
Message-Id: <XZ_z1.7$5P.88330@news2.voicenet.com>
Sara Rosso <rosso@rsn.hp.com> wrote:
>The use of certain input fields will differ from user to user, so I am
>trying to recognize an empty field and use a if-else loop to return a
>variable full of html if it has data, and return a blank variable if it
>is empty.
>
>This is the subroutine that I have so far:
>
>sub makedelivlist {
>
>$delim = ';';
>$in{'deliverables'} =~ s/\r\n/$delim/;
> if ($in{'deliverables'} != "")
> {
> @stuff = split(/$delim/, $in{'deliverables'});
> $towritedeliv = "<p><font face=\"Arial\" color=\"blue\"><b>Major
>Deliverables</b></font></p>\n";
> $towritedeliv .= "<ul>\n";
> for $i (0 .. $#stuff)
> {
> $towritedeliv .= "<li>$stuff[$i]\n";
> }
> $towritedeliv .= "</ul>";
> }
>
> else {
> $towritedeliv = "";
> }
> .
perhaps:
sub make_deliv_list
{
return '' unless exists $in{deliverables};
$in{deliverables} =~ s/\r\n//; # Possibly need a /g here?
return '' unless $in{deliverables};
$to_write_deliv =
'<p><font face=\"Arial\" color=\"blue\"><b>Major ' .
'Deliverables</b></font></p>\n';
for $stuff (split /$delim/, $in{deliverables}) {
$to_write_deliv .= "<li>$stuff\n";
}
$to_write_deliv .= '<\ul>';
}
I think your original problem comes from:
if ($in{'deliverables'} != "")
You want to use "ne" here not "!=". Check out perlop for the reason
why. I skipped that all together. A blank string evaluates to false,
so you can skip a lot of mumbo jumob by saying:
if ($in{'deliverables'})
instead of explicity testing against the empty string. The only ptoblem
with this is that that hash element will spring into existance if it
wasn't there already, that's why the test for exists should be there as
well.
--
Matt Knecht - <hex@voicenet.com>
------------------------------
Date: 11 Aug 1998 17:43:15 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Evaluating empty fields/variables?
Message-Id: <6qpvrk$otq$1@marina.cinenet.net>
Sara Rosso (rosso@rsn.hp.com) wrote:
[snip]
: The use of certain input fields will differ from user to user, so I am
: trying to recognize an empty field and use a if-else loop to return a
: variable full of html if it has data, and return a blank variable if it
: is empty.
:
: This is the subroutine that I have so far:
:
: sub makedelivlist {
:
: $delim = ';';
Might want to get into the habit of using lexicals (my) for things like
this. It'll save you from various forms of shooting yourself in the foot.
: $in{'deliverables'} =~ s/\r\n/$delim/;
Are you sure you don't want a /g qualifier on that? As written, it will
only turn the first \r\n group into a semicolon, which doesn't make sense
given the way you are using split below.
Also, no need (yet harmless) to quote 'deliverables' when used as a hash
key.
: if ($in{'deliverables'} != "")
'!=' is the numeric nonequality test operator, yet both your operands are
strings. This is a Bad Thing, and will hardly ever do what you want. You
probably mean 'ne' instead.
: {
: @stuff = split(/$delim/, $in{'deliverables'});
: $towritedeliv = "<p><font face=\"Arial\" color=\"blue\"><b>Major
: Deliverables</b></font></p>\n";
: $towritedeliv .= "<ul>\n";
: for $i (0 .. $#stuff)
: {
: $towritedeliv .= "<li>$stuff[$i]\n";
: }
A more Perlish way to write that loop is:
foreach (@stuff) {
$towritedeliv .= "<li>$_\n";
}
: $towritedeliv .= "</ul>";
: }
:
: else {
: $towritedeliv = "";
: }
:
: I reference this variable in the main routine by this line:
: print PDSTEMP $towritedeliv;
Rather than using a global variable to return the results of the function,
why not return the result as the function's value, and assign that to a
lexical variable in the main routine? This is a lot safer and easier to
debug.
: *I think my problem may be I am treating the field like number data,
: when it's really text...but I don't know how to do that. I have looked
: through several FAQ, and an ORA Perl book, but they don't have what I am
: looking for.
I find it difficult to imagine that you could have done much digging
without running into the difference between string and numeric comparison.
It's covered well in perlop, the Llama, the Camel, and every other good
Perl reference I've ever seen. Where specifically did you look?
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: Tue, 11 Aug 1998 16:02:52 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: File::Copy
Message-Id: <Pine.GSO.4.02.9808110901070.10161-100000@user2.teleport.com>
On Tue, 11 Aug 1998, Peredina wrote:
> Subject: File::Copy
>
> Using this module, is there a way to copy the correct permissions,
> particularly the executable?
When you find out how to do this, would you please add it to the docs? And
if there's not yet a way, could you implement the feature before you
document it? :-) Thanks!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Tue, 11 Aug 1998 12:52:14 -0400
From: linberg@literacy.upenn.edu (Steve Linberg)
Subject: Re: Frames
Message-Id: <linberg-1108981252140001@projdirc.literacy.upenn.edu>
In article <qp8z1UApZD01Ewao@find-it.uk.com>, Alan Silver
<alan@find-it.furryferret.uk.com> wrote:
> Before you print any HTML, print a header ...
>
> print "Content-Type: text/html\n\n";
Remember that "\n" means different things on different machines. The
really correct thing to do is this:
print "Content-Type: text/html\012\015";
But the absolutely safest thing to do is this:
use CGI;
$query = new CGI;
print $query->header;
...which is always correct, and then continue with all of the other fine
things CGI.pm does for you.
_____________________________________________________________________
Steve Linberg National Center on Adult Literacy
Systems Programmer &c. University of Pennsylvania
linberg@literacy.upenn.edu http://www.literacyonline.org
------------------------------
Date: 11 Aug 1998 16:01:03 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: help parsing mail file
Message-Id: <6qpprv$867$1@client3.news.psi.net>
Mark-Jason Dominus (mjd@plover.com) wrote on MDCCCV September MCMXCIII in
<URL: news:6qnv6r$uaa$1@netnews.upenn.edu>:
++
++ { local $ = "";
That should be
local $/ = "";
++ $header = <INPUT>; # Read entire header
++ }
Abigail
--
perl -weprint\<\<EOT\; -eJust -eanother -ePerl -eHacker -eEOT
------------------------------
Date: Tue, 11 Aug 1998 13:45:15 -0400
From: Mike Russiello <mike.russiello@tekmetrics.com>
Subject: HTML & Javascript Tests
Message-Id: <35D0832B.41EB@tekmetrics.com>
We have developed separate HTML and JAVASCRIPT tests that will SOMEDAY
be used to screen job applicants and help employees get rewarded for
learning. Right now the test is in beta and we need people to "test the
test" to see if it is any good. If you take the test your information
WILL NOT BE SHARED WITH ANYONE.
Just go to www.123apply.com and enter a pin of 'Beta JS'. The system
will give you a 12 question test three times (different questions each
time) to see how consistent the scores are. You can also comment on
each question so we can identify problems.
At completion, you will get scores between 1-5 (5 is highest). We will
post a top ten list at 123apply.com. Other than the top ten list, your
info WILL NOT BE SHARED WITH ANYONE and YOU WILL NOT HEAR FROM US.
Thanks for helping us out. Mike Russiello, TekMetrics.com
------------------------------
Date: Tue, 11 Aug 1998 13:38:31 -0400
From: pudge@pobox.com (Chris Nandor)
Subject: Re: HTML & Javascript Tests
Message-Id: <pudge-1108981338310001@192.168.0.3>
In article <35D0832B.41EB@tekmetrics.com>, Mike Russiello
<mike.russiello@tekmetrics.com> wrote:
# We have developed separate HTML and JAVASCRIPT tests that will SOMEDAY
# be used to screen job applicants and help employees get rewarded for
# learning. Right now the test is in beta and we need people to "test the
# test" to see if it is any good. If you take the test your information
# WILL NOT BE SHARED WITH ANYONE.
#
# Just go to www.123apply.com and enter a pin of 'Beta JS'. The system
# will give you a 12 question test three times (different questions each
# time) to see how consistent the scores are. You can also comment on
# each question so we can identify problems.
#
# At completion, you will get scores between 1-5 (5 is highest). We will
# post a top ten list at 123apply.com. Other than the top ten list, your
# info WILL NOT BE SHARED WITH ANYONE and YOU WILL NOT HEAR FROM US.
#
# Thanks for helping us out. Mike Russiello, TekMetrics.com
This was posted here because ... why?
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Tue, 11 Aug 1998 17:48:30 GMT
From: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: HTML & Javascript Tests
Message-Id: <Pine.GSO.4.02.9808111045440.10161-100000@user2.teleport.com>
On Tue, 11 Aug 1998, Mike Russiello wrote:
> Newsgroups: comp.lang.perl.misc
> Subject: HTML & Javascript Tests
>
> We have developed separate HTML and JAVASCRIPT tests that will SOMEDAY
> be used to screen job applicants and help employees get rewarded for
> learning.
So, why are you posting this to a newsgroup about Perl? Perl isn't HTML,
and Perl isn't JavaScript. Should movie reviews be posted to a newsgroup
about Volkswagens merely because there are drive-in theaters? :-)
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 3418
**************************************
