[12226] in Perl-Users-Digest
Perl-Users Digest, Issue: 5826 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 29 09:07:14 1999
Date: Sat, 29 May 99 06:00:18 -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 Sat, 29 May 1999 Volume: 8 Number: 5826
Today's topics:
$^O and all types? <rich_guy@hotmail.com>
Re: Alternative to deprecated scalar split <gellyfish@gellyfish.com>
Re: Alternative to deprecated scalar split (M.J.T. Guy)
Re: Application of s/// and s%%% (Jim Britain)
Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Pe (Chris Nandor)
file handling (pommes frites)
Re: Im not asking for much <gellyfish@gellyfish.com>
Is 'Global symbol "%s" requires...' Fatal? <yu5m-oonk@asahi-net.or.jp>
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl scripts won't run on Linux (Alastair)
Re: Thanks man....HOWS THIS? <gellyfish@gellyfish.com>
Upload file problem <kinmich1@lycoming.edu>
Using $_ on nested foreach degrades speed. (Charles R. Thompson)
Re: Y2K infected Perl code finsol@ts.co.nz
Re: Y2K infected Perl code <gellyfish@gellyfish.com>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 May 1999 21:38:33 -0700
From: "$Richy Rich$" <rich_guy@hotmail.com>
Subject: $^O and all types?
Message-Id: <374f6c0e.0@news1.starnetinc.com>
i'm trying to make my scripts more portable, and also make it easier for
people that use them and set them up. this of course, would involve
knowing what OS they are using. i need to check it to know if (depending
on the OS) i can use flock, do forking, etc. and what will and will not
work with windows that will work with unix, and what will and will not
work with certain versions of certain OS's. is the $^O the only thing i
can check this with? i've found that more then a few hosts don't allow
some type of commands to be executed, i.e., "ps", which makes it
difficult to kill a process id that may be sitting around too long. i'm
wondering if there's a site that lists the different OS's and how to
find out if they support flock, fork, etc. and have the script react
depending on what they do.
rich
------------------------------
Date: 29 May 1999 12:44:07 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Alternative to deprecated scalar split
Message-Id: <7ionen$28s$1@gellyfish.btinternet.com>
On 28 May 1999 14:18:35 GMT John Siracusa wrote:
>
> An ugly alternative is something like:
>
> $num_fields = @{[split(' ', $foo)]}; # Yuck!
>
Why ugly ? Thats the way I figured it after discovering that what I
thought should work :
$num_fields = () = split / /, $foo;
didnt (Why that gugus ?).
I think that its a rather pleasant, quaint idiom but thats me I guess.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 29 May 1999 12:44:49 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: Alternative to deprecated scalar split
Message-Id: <7iong1$cg4$1@pegasus.csx.cam.ac.uk>
John Porter <jdporter@min.net> wrote:
>In article <7im8jr$m4a$1@news1.bu.edu>,
> John Siracusa <macintsh@cs.bu.edu> wrote:
>> "implicit split to @_ is deprecated" according to the docs.
>> Fine, but what do I do when I *want* to use split in a scalar
>> context? It's a shame that grabbing just the
>> number of fields ends up squashing @_. What are my options
>> here? Is there a better way to do this? Example:
>>
>> $num_fields = split(' ', $foo); # Bzzzt! Deprecated!
>>
>> but the real goal here is just to get a scalar value, without
>> saving the fields in any array: @_, temporary, or whatever.
>
>$num_fields = () = split .....
Heh, heh! You didn't test that, did you?
Hint: split has an optimisation to only split into as many fields as
needed.
Mike Guy
------------------------------
Date: Sat, 29 May 1999 08:12:13 GMT
From: jbritain@home.com (Jim Britain)
Subject: Re: Application of s/// and s%%%
Message-Id: <374f9f76.14115770@news>
[posted and mailed]
On Sat, 29 May 1999 06:40:14 GMT, wired2000@my-deja.com wrote:
>The example suggestion that was posted to this newsgroup involved
>implementing a regexp such as: s%^[a-z][a-z\d.+-]*://[^/]+%%i;
>But how to tell Perl to do this to is bugging me.
>
>Any ideas?
It's called the binding operator:
=~
$in{'URLlist'} =~ s%^[a-z][a-z\d.+-]*://[^/]+%%i;
Do perldoc perlop, and then search with /Binding for an explanation.
------------------------------
Date: Sat, 29 May 1999 12:50:20 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Message-Id: <pudge-2905990850260001@192.168.0.77>
In article <7iilcm$1dl$1@nnrp1.deja.com>, finsol@ts.co.nz wrote:
# In article <slrn7klkcn.mq8.sitaram@diac.com>,
# sitaram@diac.com (Sitaram Chamarty) wrote:
# >
# > I think the lady means "that real world in which "consultants" can
# > make lots of moolah by spreading unnecessary FUD about Y2K, and
# > where they (as well as trial lawyers) are panicking at the thought
# > of NOTHING major happening, and trying their damnedest to make hay
# > before the sun starts shining again".
# >
# So, you work for nothing do you? When do you get your sainthood?
I work for nothing. I spend hundreds of hours a year programming cool
stuff for other people because that's what I like to do. I don't expect
sainthood, just a simple "thank you" now and again. Though sometimes I
feel guilty for expecting that, but no one is perfect.
# Whether a method of instructing a computer can be deemed a programming
# language, scripting language, interface language, job control language
# or some other esoteric jargon you would care to name, is a grey area
# that I don't wish to debate. The fact is that CGI shares the same Y2K
# booby-trap problem as Perl. Fixing Y2K problems is more important than
# playing stupid semantics.
That is a completely ignorant statement. CGI has no Y2K problem. CGI
doesn't have any date functions or data structures. It cannot create or
return a date. CGI cannot have Y2K problems. It is only an interface.
That's like saying my computer screen has Y2K problems. It is not "stupid
semantics", it is just plain stupid.
In article <7ikqh8$jv4$1@nnrp1.deja.com>, you wrote:
# If Perl code can be infected with Y2K problems, then so can CGI routines
# - deny that if you can!
There is no such thing as a CGI routine, though. Never has been, never
will be.
And of course, you still maintain that Perl has Y2K problems when it
doesn't. Only programmers of Perl (and every other language) have Y2K
problems.
You can claim that localtime() returning years since 1900 is a design
flaw, I suppose, but that's useless to do, as it cannot be changed and
doesn't help anything to call it a flaw, and it is perfectly compliant
with the available standards. Certainly, there is no evidence to prove it
is a flaw, all it is is an opinion. A valid opinion, I suppose, but only
an opinion, not a fact. It is good to let people know that localtime()
returns years since 1900, for those that don't already know it, but to
blame it on Perl or its very clear and accessible documentation is wrong.
In article <7imt5t$3ep$1@nnrp1.deja.com>, finsol@ts.co.nz wrote:
# Lane's point still holds - a programmer can create Y2K problems in COBOL
# and in Perl. Just because a particular language makes this particularly
# easy to do (as with Perl and as with languages that have non-compliant
# components) doesn't change the fact.
There is nothing non-compliant about Perl. Stop lying. There is no
recognized standard that says all years must be returned in years since
year 0. In fact, it is the other way around: Perl is compliant with the
recognized standards that call for it to return years since 1900.
# Tough shit for who? Just think about it. Who is going to suffer from all
# this denial and ignorance the most? There is certainly a problem Perl
# developers if they can be so blase about the consequences of Y2K
# problems within the organisations which use the Perl progranmming
# language.
Who's blase about it? We tell people how to program properly. We tell
them to read the docs, give them examples of what to do and what not to
do. In our own programs, we program properly and in our organizations we
make sure others do, too, when it is possible to do so. After all that,
if people refuse to read the docs, refuse to think properly, refuse to
code properly ... it's just not something I or most reasonable people are
going to stay up worrying about. Some things are out of my control, and
the stupidity of other people is one of them.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Sat, 29 May 1999 09:25:42 GMT
From: pommes.frites@gmx.net (pommes frites)
Subject: file handling
Message-Id: <374fb0b2.5979876@news.univie.ac.at>
hi i am a beginner in perl and i have the following problem ...
i create a file "lva.tmp" in my progarm (its a file with text entries)
and i want to overwrite the entries in "lva.dat" with those in
"lva.tmp".
i have written this code and it doent work
open(Ziel,">lva.dat");
open(Quelle,"<lva.tmp");
while(<Quelle>) {
print Ziel $_;
}
so my questions ...
is this code ok?
does anyone know a better one? (dele .dat file and rename .tmp file)
do i have to set special rights for these files?
thanx for help ...
-pommes
------------------------------
Date: 29 May 1999 12:31:03 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Im not asking for much
Message-Id: <7iomm7$28o$1@gellyfish.btinternet.com>
On Fri, 28 May 1999 19:35:48 GMT jknoll@my-deja.com wrote:
> I just wanted to try and learn this language from the ground up. I
> wanted to make sure I knew WHY things happened when they did, not just
> how to make it look right. I guess this wasnt the right place to start,
> no one here really seems to want to give me a hint, so I am not real
> optimistic about my next request; If I can't get help here, does anyone
> have any idea where a starting perl programmer should start?
>
Look,
There is a great culture of self-reliance amongst the Majority of people
who post to this group regularly - self-reliance in this case means that
we like to see some evidence of any attempt to solve a problem yourself.
Perl comes supplied with a fine set of documentation - you can start off
with:
perldoc perl
At the command prompt of whatever system you might find yourself on.
Your particular question will be answered in the perlop document:
perldoc perlop
And look for the section entitled:
Quote and Quote-like Operators
Hope that helps.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Sat, 29 May 1999 19:14:21 +0900
From: "Makoto Ohnuki" <yu5m-oonk@asahi-net.or.jp>
Subject: Is 'Global symbol "%s" requires...' Fatal?
Message-Id: <7ioehp$7ba$1@father.asahi-net.or.jp>
Hello.
I want to create subroutine in eval '' . (subroutine body is defined another
file by somebody)
For find strange code , I create sub with 'use strict qw(vars subs refs)' .
But, in case of above program, I get this result,
Global symbol "$no_var" requires explicit package name at (eval 1) line
4.
die2:Undefined subroutine &Runtime::foo called at ./evtest.pl line 17.
Why I cannot catch this error at eval-1?
Otherwise, Why foo() is not created?
== evtest.pl ==
#!/usr/bin/perl -w
my $src = <<'EOF';
package Runtime;
use strict qw(vars subs refs);
sub foo {
return $no_var;
}
EOF
eval $src; # eval-1
if ($@) {
die "die1:$@";
}
eval {
Runtime::foo();
};
if ($@) {
die "die2:$@";
}
------------------------------
Date: 29 May 1999 07:56:33 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <927964754.999114@localhost>
armchair@my-deja.com wrote:
>snip<
: Since the looping and decision constructs of Perl are the same as C and
: C++, and since C++ now has a string class, perhaps it is the dynamic
: arrays and dynamic hashes that have you rolling on the floor and laughing.
: Well, via the Standard Template Library (STL), those data structures also
: exist in C++ as well (few, if any vendors are not shipping the STL with
: their compiler). What then puts Perl at a higher level than C++? Regular
: expressions?
Non sequitur. If you add hash and string macros to assembly, would
it be as high level as Perl and C++? I think not.
: my @array = <FILE>; is nice, but once you write similar routines in C++,
: you also have complete control over the error handling.
Ditto for assembly, quite a bit more so actually.
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: 29 May 1999 08:17:43 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <927966025.384456@localhost>
armchair@my-deja.com wrote:
>snip<
: Scalar variables in Perl (numbers, strings, references to
: (numbers,strings,hashes,arrays,objects)) are all identified the same.
:
: my $variable.
>snip<
: Only pointers declared as void can point to any variable, and then you
: can't dereference them unless you cast them to the appropriate pointer -
: you must ultimately know they type of what they point to.
If it helps, think of my as void, and just as in C++ you still have
"cast them to the appropriate pointer" and "ultimately know they
type of what they point to":
@$myArray ala (Array)myArray
%$myHash ala (Hash)myHash
*$myGlob ala (fd)myIO
$$myScalar ala (void)myScalar :-}
>snip<
: Overloading of operators in Perl? I guess I missed that in perlobj.
perldoc overload
>snip<
:> The philosophy of OO says that types should be abstracted. Different
:> systems abstract them to different levels, and perhaps the best we
:> can say is that this is proper. In Perl, it was decided that -- most
:> of the time -- numbers and strings should be dealt with via a common
:> abstraction, i.e. a common superclass.
:
: If I have a date/time object, the "philosophy of OO" may say that I don't
: need to know how it is represented, but they have nothing against me
: knowing that it represents dates and times. But with my $a =
: somefunction(); I don't know whether $a represents date/times or is a
: count of the number of times some functionality in Perl is represented as
: having arose from long and deep thought.
...And yet, somehow:
int a;
a = somefunction();
Tells you so much more...?
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: 29 May 1999 08:27:34 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <927966616.318160@localhost>
armchair@my-deja.com wrote:
>snip<
: Always remember the Perl motto: "There's more than one way to do it -
: TMTOWTDI". With a motto like that, you would think that there would be
: a great acceptance of all the diversity of code stylings. Every color of
: variable naming, all code structuring religions, and every crede of
: oject definition.
Simply because methods > 1, it does not follow that methods ==
Infinity, or even that scalar grep /C/, @waysToDoIt won't == 0.
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: Sat, 29 May 1999 09:06:29 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: Perl scripts won't run on Linux
Message-Id: <slrn7kvf42.5f.alastair@calliope.demon.co.uk>
jmoram@my-deja.com <jmoram@my-deja.com> wrote:
>I've just set up at a Linux box as an intranet server. Perl seems to be
>installed ok, but I can't seem to run scripts. The GNU C compiler is
>installed and I've made sure the scripts are executable, but when I give
>the command to run them, I get this message:
>$ bash: command not found <scriptname>
It could be one of the classics ;
1) the first line of the script doesn't have the correct path to Perl i.e.
#!/usr/bin/perl -w
2) you don't have '.' (current directory) in your path which means you need to
run the program as ;
./program
HTH.
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: 29 May 1999 11:18:22 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Thanks man....HOWS THIS?
Message-Id: <7ioidu$284$1@gellyfish.btinternet.com>
On 28 May 1999 20:51:57 GMT I R A Aggie wrote:
> On Fri, 28 May 1999 19:39:50 GMT, jknoll@my-deja.com <jknoll@my-deja.com>, in
> <7imre6$24h$1@nnrp1.deja.com> wrote:
>
> + perl for my summer job. I couldnt find out how to do it, so i thought
> + someone here would know.
>
> 'perldoc perl' is your friend. Once you have become familiar with it,
> and learnt how to 'grep' its wisdom, you'll be able to come up with
> your own solutions in a much more rapid fashion than relying upon
> usenet, making you look smart *and* handsome, causing the PHB to give
> you a raise and promotion (without any real reason), and having babes
> chase you down and beg you to be the father of their children...
>
I guess I must be doing something wrong - anyhow I get a hard time from
Mrs Gellyfish if the 'babes' started doing that ;-}
/J\
--
Jonathan Stowe <jns@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Fri, 28 May 1999 16:33:41 -0800
From: lunaboy <kinmich1@lycoming.edu>
Subject: Upload file problem
Message-Id: <927938023.470@www.remarq.com>
I'm writing a cgi script that takes a file from the user's
local machine and uploads it to the server the script is
running on. I'm not having any luck at all. I'm using
perl/mySQL/CGI.pm and trying to save 2 types of files: image
and text.
What it needs to do is use an HTML form to get the file from
the user, and upload it to /cgi-bin/text or /cgi-bin/img. I
have the directories chmod'ed to 777, but when it creates
the file:
open(LOCAL, ">$local_filename") or die "$!";
it creates a file that's chmod'ed 744.
Can anyone suggest an easy way, a module, anything that can
help me with my problem?
Thanks in advance
-Mike King
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
------------------------------
Date: Sat, 29 May 1999 08:22:14 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Using $_ on nested foreach degrades speed.
Message-Id: <MPG.11b96f40353e66b69896d6@news>
Playing with Benchmark lately has been doing wonders for my code studies.
I'm learning all kinds of ways to squeeze every last bit I can out of my
code. I've come across something and have question if someone has the
time. below is a snippet (useless without the rest of the script... but a
valid example...)
my $r = 0;
my $row = '';
my @cache = '';
my $temphold = $TABLES{$CUR_TABLE};
foreach $row(@temp){
@cache = split(/\|/, $row);
foreach (sort keys %{$temphold->{fields}}){
$temphold->{rows}[$r]{$_} = $cache[$temphold->{fields}{$_}{col}];
}
$r++;
}
In this loop I have noticed that using $_ with foreach loops really gets
me some speed on the inner loop. However.. outer loops are a different
matter. The outer loop seems to degrade by about 7-8/10's of a second
when I do this...
my $r = 0;
my @cache = '';
my $temphold = $TABLES{$CUR_TABLE};
foreach (@temp){
@cache = split(/\|/, $_);
foreach (sort keys %{$temphold->{fields}}){
$temphold->{rows}[$r]{$_} = $cache[$temphold->{fields}{$_}{col}];
}
$r++;
}
Is this because $_ was set in the outer loop and Perl has to do some kind
of initialization when it is set again on the inner loop?
--
CT
------------------------------
Date: Sat, 29 May 1999 07:59:34 GMT
From: finsol@ts.co.nz
Subject: Re: Y2K infected Perl code
Message-Id: <7io6p6$v4h$1@nnrp1.deja.com>
In article <374edeff@cs.colorado.edu>,
tchrist@mox.perl.com (Tom Christiansen) wrote:
> [courtesy cc of this posting mailed to cited author]
>
> In comp.lang.perl.misc,
> docdwarf@clark.net () writes:
> :happens if the person writing code is not a 'retard' but the specs
demand
> :certain standards be adhered to.
>
> Have you considered toiling under a slightly less mind-numbingly
> fascist regime?
>
> --tom
> --
Tom's right here - for once! Most IT departments allow programmers to do
whatever they like in programs. 99.99% of the time if we don't like the
spec we do what we like - who looks at our code anyway?
Can't tell me programmers 'were made to do it that way'. That excuse
for Y2K botch ups looks lame to me. We prima donnas have always been
able to do pretty much anything we like with the code. Can't see any
manager telling a programmer what to do and run the risk of him/her
quitting in a huff! Or worse still, coming back at them with some techno
rave guaranteed to make no sense, therefore making them look stupid.
Which is of course the whole intention. Good trick that - if the
non-initiated look like they are grasping a little of the techno stuff,
turn up the jargon knob enough notches to really confuse them.
No, you're right Tom - if the spec is stupid or we just plain don't like
it, we can still do it however we like - and no-one is ever going to
know. And chances are if and when they do find out, we'll be long gone.
So, DD, your workplace must be in the minority. What, you get specs?
They actually specify what is to happen at code level? Maybe you even
have standards? And there's someone around to police them? They actually
look at your code?
Of the 100 or so work environments I have programmed in I can't even
think of one that has been so draconian. You are most unfortunate!
Guaranteed your creative abilities won't be stifled in your next job.
Unless you are extremely unfortunate.
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: 29 May 1999 11:05:19 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Y2K infected Perl code
Message-Id: <7iohlf$280$1@gellyfish.btinternet.com>
In comp.lang.perl.misc finsol@ts.co.nz wrote:
> In article <374e7842@newsread3.dircon.co.uk>,
> Jonathan Stowe <gellyfish@gellyfish.com> wrote:
>> In comp.lang.perl.misc Lane Core Jr. <elcore@sgi.net> wrote:
>> > On 27 May 1999 22:47:28 -0400, Uri Guttman <uri@sysarch.com> wrote:
>> >
>> >>so fucking what if cgi
>> >>routines and perl routines can be infected with y2k. that is the
>> >>programmers problem and not the language's.
>> >
>> > same with cobol.
>> > same with any language.
>>
>> Not entirely true - there are languages with a DATE type that is
> completely transparent to the programmer:
>>
> <SNIP - geek stuff>
Oh I am sorry but if you are going to get involved in a thread like this
with real programmers, real analysts and real engineers then you are going
to have to deal with it.
Oh and it was Informix 4GL not really a great favourite with the 'Geek' set.
>>
>> I love it when it when a crosspost goes bad ...
>
And I mean this most sincerely folks: the poor people in
comp.software.year-2000 must be wondering what they done to deserve it.
> Lane's point still holds - a programmer can create Y2K problems in COBOL
> and in Perl. Just because a particular language makes this particularly
> easy to do (as with Perl and as with languages that have non-compliant
> components) doesn't change the fact.
>
I'm afraid your logic has confounded me there. The second sentence doesnt
seem to belong in the same paragraph as the first.
Asserting that a language makes it easy to create Y2K problems is totally
bogus. Programming is not supposed to be easy. Programmers are supposed
to know what they are doing; they are supposed to read the documentation.
You might as well be ranting on in comp.lang.c about 'The core dump problem
and programmer denial' for all its value.
> Y2K problems can occur in applications written in any programming
> language and all programming languages can be used to write non-Y2K
> problem applications.
>
Sure if the person writing those programmes is inept, if they havent paid
a bit of notice what the documentation says about date handling or perhaps
worse they didnt understand or chose to ignore it. In the aforementioned
Informix 4GL they would have to go out of their way to do so of course
because of the DATE type - an Informix installation need be configured
once and it will cause all date representaions with two digit years to
be thrown out as an invalid date format (right or wrong who knows ?).
Thinking about it where did this $year = '19' . $year originate anyhow ?
Who here, in the abscence of the documentation of course, seeing that
localtime returned a 2 digit year would have prepended the century rather
than add 1900 even in total ignorance of what it actually was, because it
is after all a number rather than a string.
>> I think that uri's point is that basically if someone is too dumb to
> have read and understood the documentation for the localtime function
> then its basically tough shit - it is not a problem with Perl its a
> problem with the meatware.
>> /J\
>> --
>> Jonathan Stowe <jns@gellyfish.com>
It really is rather lame to quote peoples signatures unless you have
some point to make thereof.
>
> Tough shit for who? Just think about it. Who is going to suffer from all
> this denial and ignorance the most?
Er. People, Consultants like you have no contribution to make but to
snipe from the sidelines whilst the real programmers get on and do their
work properly as they always have done. People who got whipped up into
a financial feeding frenzy by all of the hype over the so called
'Millenium Bug' and figured they'd cash in too only to discover all the
really juicy targets had all been covered. Baby you just bombed the
Chinese Embassy.
Neither I nor any of the other contributors to this newsgroup are denying
that there are 'programs' out there that have made incorrect use of the
year value as returned by localtime: but we also know of other 'programs'
which run the risk of failing *every time they are run* because their
authors had failed to consult the documentation or understand it: do we
see a great community hand wringing for this latter group as you seem
to suggest we should for the former? I dont own a hair shirt, but if
I did I certainly wouldnt have any intention of wearing it just because a
programming language that I use is misused by others.
And believe neither I nor the majority of Perl Programmers are going to
get upset when some Script Kiddies guestbook or discussion board ceases
to work at the beginning of January next year.
> There is certainly a problem Perl
> developers if they can be so blase about the consequences of Y2K
> problems within the organisations which use the Perl progranmming
> language.
>
And what, pray tell, are we supposed to do about it ? Form the 'Perl
Localtime Abuse Cabal Action Team' (PLACATE for all of you who like
acronyms) put on ski masks, kick down the door of Matt Wrights bedroom
and fix all of his scripts before Big Ben rings twelve ? Come over all
Perl-O-Cop : 'You-Have-Two-Hundred-and-Twenty-One-Days-to-make-your-code
compliant' ? Hey, we could change the Artistic Licence to contain a
clause that makes it illegal to run perl against code that misuses
localtime() and take all those nasty perps to court. Come on, tell us
what *you* think we should be doing about it - given that every last one
of us (that is professional programmers not the others) is sure that we
have not created nor maintain any code that perpetuates misuse of date
values in Perl or at least certainly know what to be fixed.
But the worrying thing here is I still dont know where you are coming from.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: 12 Dec 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 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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 5826
**************************************
