[9978] in Perl-Users-Digest
Perl-Users Digest, Issue: 3571 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 28 05:03:04 1998
Date: Fri, 28 Aug 98 02: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 Fri, 28 Aug 1998 Volume: 8 Number: 3571
Today's topics:
Re: Bit of humor <rra@stanford.edu>
CGI Form Refresh <alatham@internet.dk>
Re: comp.lang.perl.windows.misc (Bob Trieger)
Re: comp.lang.perl.windows.misc (Norman UNsoliciteds)
Re: Determining strlen <dave@nic.com>
Re: Determining strlen <dave@nic.com>
Re: directory chmod <nobody@nowhere.com>
Grabbing params from one CGI to another <jbharvey@auspex.net>
Re: Looking for Advice greene@gucc.org
Re: Misinterpreted => why no true/false keywords? (Mark-Jason Dominus)
Re: Misinterpreted => why no true/false keywords? (Mark-Jason Dominus)
Re: Misinterpreted => why no true/false keywords? <rra@stanford.edu>
Re: newbie question (Bob Trieger)
Re: newbie question (Norman UNsoliciteds)
Re: newbie question (Norman UNsoliciteds)
Re: Perl compiler ()
posting to a program, receiving results <dan@bns.com>
Re: Win32 and Perl <jwb79@mail.idt.net>
Re: Y2K Date Support (Larry Rosler)
Re: Y2K Date Support <mee@mine.com>
Re: Y2K Date Support <rra@stanford.edu>
Re: Y2K Date Support (Maurice Aubrey)
Re: Y2K Date Support <rra@stanford.edu>
Re: Y2K Date Support (Craig Berry)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 27 Aug 1998 23:17:13 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Bit of humor
Message-Id: <m3pvdlpr4m.fsf@windlord.Stanford.EDU>
nobody <ac1@fspc.netsys.itg.telecom.com.au> writes:
> # Get the current date/time and pid from the system. Note the sneaky
> # trick to decide which century we are in. If you're reading this
> # in 2069, my apologies: you think we would have learned from the
> # Y2K crisis - now you know better. If you're looking at this code
> # to ensure it passes the 32-bit-UNIX 2038 bug, please fix this as
> # well; we're far too busy on Y2K at the moment :-).
> ($Sec,$Min,$Hr,$MDay,$Mon,$Yr,$Junk,$Junk,$Junk) = localtime( time );
> $Yr += ($Yr < 70) ? 2000 : 1900;
The hilarious part is that, provided that the vendor's localtime continues
functioning after 2038, this code will continue working just fine in
perpetuity, as $Yr is never going to be less than 70. :)
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Fri, 28 Aug 1998 10:54:16 +0200
From: "Ashley Latham" <alatham@internet.dk>
Subject: CGI Form Refresh
Message-Id: <6s5r66$100e$1@news.net.uni-c.dk>
Hi,
I have a form set up that calls a perl script. After data is entered the
script checks the data, adds it to the database and returns a html page
stating the data has been added or there was an error in the data entry.
All this works fine.
On some browsers when I hit the browser back button I can see the form with
all the information I have entered as it was just before I hit the submit
button. This is good in that if an error has been made with the data entry
the entire form doesn't need to be re-entered, only the fields that are
wrong. On other browsers when the browser back button the form is refreshed
and reset to the initial empty fields.
Can someone tell me if there is anyway to control this, or at least which
browsers reset the form and which don't and why?
Thanks, any help would be appreciated
ashley
------------------------------
Date: Fri, 28 Aug 1998 04:51:12 GMT
From: sowmaster@juicepigs.com (Bob Trieger)
Subject: Re: comp.lang.perl.windows.misc
Message-Id: <6s5d65$plv$1@ligarius.ultra.net>
elistan@metronet.com (Mark) wrote:
-> I'd be very interested in seeing comp.lang.perl.win32. So one
-> day a couple weeks ago my boss says "Hey Mark, what do you know about
-> Perl?" I reply, "Uh, it's, like, a scripting language?" "Well, go learn
-> it. I think it could help us" "Uh, okay." (I'd be interested in the
-> win32 group not so much to ask/answer questions like "How do I use
-> hashes?" <grin> or "Why doesn't QueryValue give me back an object
-> reference?" [Which I still don't know the answer to, but at least I found
-> on the web a different way to do it.] Rather, I've very interested in
-> WHAT sort of things people are using Perl for in a win32 environment,
-> instead of HOW to do stuff.)
There isn't that much of a difference on the win32 platform than any
*nix platform to merit its own newsgroup.
But I am all for comp.lang.perl.win32 and probably for the same reasons
as Bacon et all. It would slow down the FAQs and off topic posts in
c.l.p.m made by the 12 year olds whose parents use the net as a free
baby-sitter. I just take exception to people calling all Win32 users
clueless.
Bob Trieger
sowmaster@juicepigs.com
" Cost a spammer some cash: Call 1-800-400-1972
Ext: 1949 and let the jerk that answers know
that his toll free number was sent as spam. "
------------------------------
Date: Fri, 28 Aug 1998 17:06:18 +0900
From: No.unsoiliciteds@dead.end (Norman UNsoliciteds)
Subject: Re: comp.lang.perl.windows.misc
Message-Id: <No.unsoiliciteds-2808981706180001@cs11n47.ppp.infoweb.or.jp>
In article <904160237.11666.0.nnrp-08.c2deb1c5@news.demon.co.uk>, "Daniel
Adams" <dan@fearsome.net> wrote:
> comp.lang.perl.rude.arrogant.perl.afficionados
> comp.lang.perl.hotheaded.perl.gurus
> comp.lang.perl.i-want-to-fellate-larry-wall
> comp.lang.perl.fuck.people.who.are.trying.to.learn.perl
> comp.lang.perl.what.the.hell.makes.you.think.this.is.a.perl.newsgroup.fuck.o
> ff.newbie
> comp.lang.perl.bitch.bitch.bitch
Hey I'd subscribe to those, it'd be just like this NG so I'd feel kind of
at home. The devil you know and all that
--
The Dinosaurs were so stupid, they couldn't
even devise the means of thier own extinction,
they had to wait for Nature to do it for them.
------------------------------
Date: Fri, 28 Aug 1998 01:45:44 -0400
From: Dave Wreski <dave@nic.com>
Subject: Re: Determining strlen
Message-Id: <35E64408.69D15B6D@nic.com>
> > if ($str =~ /<A HREF=http:*>/)
> > ...
> >
> > Argh, very frustrating, and the FAQ is more complicated than I"m ready for
> > right now.. I just haven't had the time to learn how to do this..
>
> Nooooooooo! Pleassssssse Donnnnnnnnn't
>
> If you're looking to parse html use the module.
Which module?
> Doing it by hand like
> this /only/ works if you're the one making the html so that you can
> control what goes in it. /IF/ that is the case then what you want is
> not the above but instead : if ($str =~ /<A HREF=(http:.+?>)/) and then
> proceed with $1. But use this IF and ONLY if you can guarantee that you
> won't have url's like:
>
> <A HREF =
> "http://search.dejanews.com/msgid.xp?MID=<35E5BC57.AA9F102C@nic.com>">Me
> ssage from Dave</A>
>
> (btw - you need to set netscape to wrap at around 72, not 90.
It's currently set for 72.... I wish I could find a better news client...
Dave
------------------------------
Date: Fri, 28 Aug 1998 01:54:47 -0400
From: Dave Wreski <dave@nic.com>
Subject: Re: Determining strlen
Message-Id: <35E64627.35A74DD7@nic.com>
> If you're looking to parse html use the module. Doing it by hand like
> this /only/ works if you're the one making the html so that you can
> control what goes in it. /IF/ that is the case then what you want is
> not the above but instead : if ($str =~ /<A HREF=(http:.+?>)/) and then
> proceed with $1. But use this IF and ONLY if you can guarantee that you
> won't have url's like:
>
> <A HREF =
> "http://search.dejanews.com/msgid.xp?MID=<35E5BC57.AA9F102C@nic.com>">Me
> ssage from Dave</A>
Hmm.. That doesn't quite work either. That still gets the whole URL. How can
I just get either the URL itself, or the data between the closing > and the
</A>?
Argh. Thanks again,
Dave
------------------------------
Date: Fri, 28 Aug 1998 15:45:09 +1000
From: Allan Chandler <nobody@nowhere.com>
Subject: Re: directory chmod
Message-Id: <35E643E5.9FABE04C@nowhere.com>
David Hawker wrote:
> Does anyone else get error message from their news server, "more included
> text than new text"? I've heard this is in fact produced by the newsreader
> not the server??
>
I think so. I get this problem under Netscape 4.04 for HP-UX but NOT
with rtin running on the same box.
AC.
------------------------------
Date: Fri, 28 Aug 1998 01:50:50 -0700
From: Justin Harvey <jbharvey@auspex.net>
Subject: Grabbing params from one CGI to another
Message-Id: <35E66F6A.986CB1B8@auspex.net>
Here is an interesting problem.
I have an html page that has a form. Whenever I put in values into
form, and then post it to my foo.cgi (perl script) I can use those
values by doing
$variable = $q->param('variable');
Now, what happens if I need to go from html to cgi1 to cgi2?
I need my variables to migrate from the html to the cgi2, from html to
cgi1 is fine, from cgi1 to cgi2 is fine, just that html to cgi2 doesn't
work.
I've tried things like:
@names $q-param;
foreach (@names) {
$value = $q-param($_);
$q->param(-name=>$_,-values=>$value);
}
The above code would be placed in cgi1, hoping to copy all the params
from the html into new params and passing them to cgi2. ARGH.
------------------------------
Date: Fri, 28 Aug 1998 08:17:49 GMT
From: greene@gucc.org
Subject: Re: Looking for Advice
Message-Id: <6s5p3b$lq3$1@nnrp1.dejanews.com>
In article <01bdd0a8$10190440$3896cdcf@hp-customer>,
"George H" <george@tapestry.net> wrote:
> I have a problem I am trying to solve that has me miffed.
>
> Basically, I want to run 2 cgi's on 2 different servers from the same web
> page form passing the same 'QUERY_STRING' to each program. Currently the
> form executes a local cgi ... but I would like to pass the same information
> to another cgi on another machine as well.
>
> Would it be best to open a socket connection to the server and manipulate
> the database that way? or ... there is a similar cgi on the distant server
> ... can I pass it the query string with a HTTP request. Anyone run into
> something like this in the past?
>
> Regards,
>
> George
>
I personally haven't tried it, but I would approach this with the CGI:: and
LWP:: modules. Basically, all you have to do is parse the input to the 'local'
script with the CGI:: functions, then do whatever processing needs to be done
locally. The fire off a call to the 'remote' URL with the LWP:: functions, and
output whatever you get back. If you want to merge the outputs from both the
local and remote CGI calls, you'll have to remove some parts of the HTML, like
the second "Content-type" and <HEAD> sections.
My instinct is to stay away from raw socket calls, especially when some nice
people have already encapsulated these into an (sometimes) easy-to-use
module. I don't have the time to spend re-inventing the wheel.
HTH,
JAGreene
--
# James Greene - Informatics Consulting - D-79539 Loerrach, Germany
# Internet: www.gucc.org/greene/consult - greene@gucc.org
# PGP Fingerprint: 8930 41E7 351B 56D8 801C D4D9 4C76 AF0F E24E F307
perl -we "$_=join'<',qw{d2by' f5e;f4z($iu w0@86yo=&ae b!097)l(&aa8vme
b$*};$_=unpack'u*',uc;print"
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: 28 Aug 1998 01:58:19 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Misinterpreted => why no true/false keywords?
Message-Id: <6s5gtr$580$1@monet.op.net>
In article <904273351.65674@thrush.omix.com>,
Byron Brummer <zenin@bawdycaste.org> wrote:
> Just short of 1,094,
968 in version 5.004. 1,094 in version 5.005. But as you point out,
it's really only 458 lines (or 474) because the other half is documentation.
Only 458 lines to replace one one-line subroutine definition. Not 1,094.
Gosh, that makes it a totally different situtation. What was I thinking?
:)
> Of course, if you gave up your obsession with obfuscating your code
I hope we can conduct this discussion without making personal remarks,
and without drawing insulting inferences about people we do not know.
I would certainly prefer it.
> sub true () { 1 };
I agree that this is much better than the glob solution. You are
absolutely right, and I was a complete space case to forget about it.
I'm very glad you showed this, because it is wearing a shirt that says
`Hi! I am the final nail in the coffin of constant.pm!''
> your advice to subvert constant.pm is flawed.
Really? I found your one-line argument above to be very persuasive.
constant.pm is a cute and clever piece of syntactic sugar, but that's all.
> And now "use Foo ()" still imports foo(), *DESPITE* my *EXPLICITLY*
> asking that *NOTHING* be imported. Gee, thanks... :-(
That example was specifically discussing a module whose *only* purpose
was to define and export a certain function; it said so right up
front. If you didn't want the function, you wouldn't use the module.
It was either careless or dishonest of you to ignore this.
The purpose of the example is to present the simplest possible
demonstration of exporting, to set up discussion of better, more
complete methods later on. `Exporter' has a little bit of magic and a
big pile of mundane detail. The mundane details are straightforward,
but the magic scares people off.
By distilling out the one drop of magic, I can show how it works
without cluttering the explanation with a lot of mundane details. The
mundane details are more easily deducible, and can appear later.
>> This bears careful study, because it's so useful and so simple.
>
> No, this "bears careful study" because it's error prone, rude,
> and extremely unexpected.
That too. The techniques and features that underly something as
fundamental and important as the Exporter certainly deserve careful
study in great detail. Regrettably, my talk was only forty minutes
long, so I couldn't be as complete as I'd like to have been.
Fortunately, once you understand the basic idea of how the Exporter
works, it's no trick to read the source code and see where EXPORT_TAGS
is being handled. EXPORT_TAGS is totally straightforward, so there's
no point in discussing them. ``Oh, it's a hash.'' Instead, I spent
the time discussing the cryptic and mysterious part of the Exporter
that does not yield to inspection.
> You seem to like short code,
Short code when warranted; longer code when appropriate. 458 lines is
too big to replace `sub true () { 1 }', as I'm sure you agree.
> so why not just do:
>
> print "6 * 7 + 5 = @{[6 * 7 + 5]}\n";
Oh, a few reasons. Perhaps you find the @{[]} trick distasteful
because it has so much punctuation; some people do. If I were
obsessed with obfuscation, I might prefer it. The @{[]} trick also
has the possibly surprising and probably undesirable property of
evaluating the expression in list context:
> print "The time is now @{[localtime()]}\n";
The time is now 42 27 1 28 7 98 5 239 1
Oops, I wanted it to say
The time is now Fri Aug 28 01:28:11 1998
I guess I'll have to use something like
print "The time is now @{[scalar localtime()]}\n";
print "The time is now ${\do {localtime()}}\n";
print "The time is now $eval{localtime()}\n";
Of course, your preference may vary, but I find the last version the
best here.
The technique I showed is also more flexible and more generally useful
than the @{[]} trick, because the `fetch' routine can format the
result in an arbitrarily useful way:
$INCOME = -37092.5;
print "Total income: $dollars{$INCOME}\n"
# prints Total income: ($37,092.50)
But finally, I think your question is misguided. ``Why not just do
this'' is very nice, if you already know the trick. But if you don't
know the trick, the `just' goes away and leaves you with ``Why not do
this'', and then the answer is ``No reason. There's more than one way
to do it, and this is another way. Judge both and use the one that
seems appropriate.''
> Or, we could learn to use open(2) flags and sysopen() correctly.
What's your complaint here? That I didn't present the Ultimate Guide
to File Locking? Sorry! But when I decide to give a talk on that
subject, I promise I'll title it appropriately.
The solution I presented is more flexible and more portable than
yours; it's simple and straightforward, involves no new knowledge at
all and doesn't depend on system-dependent features of `sysopen'.
As usual, there's more than one way to do it. I showed one way. Your
complaint that I didn't show *your* way is irrelevant.
Hoping that your reply, if there is one, is lacking in further abuse.
My obsessions are not available for your perusal.
------------------------------
Date: 28 Aug 1998 02:06:02 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Misinterpreted => why no true/false keywords?
Message-Id: <6s5hca$5a9$1@monet.op.net>
In article <904273351.65674@thrush.omix.com>,
Byron Brummer <zenin@bawdycaste.org> wrote:
> Better do that with append and read (+>>) or seek(FH, 0, 0) won't
> work the way you need it to.
Actually, I think you better do that with +<, or the write may not
work the way you want it to.
But who's counting?
------------------------------
Date: 27 Aug 1998 23:07:29 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Misinterpreted => why no true/false keywords?
Message-Id: <m3vhndprku.fsf@windlord.Stanford.EDU>
Byron Brummer <zenin@bawdycaste.org> writes:
> Constant.pm is only one 21 line sub. Strict.pm, vars.pm, and
> Carp.pm (and therefor Exporter.pm) you're *very* likely to be
> pulling in anyway so including them is of little to no extra
> expense.
strict.pm and vars.pm I can buy. I consider it a bug in the standard
library that everything pulls in Carp.pm when one can just as easily do:
if ($something_failed) {
require Carp;
Carp::croak ("Wow, something failed!");
}
> Yes, it would be nice if constant.pm auto-included Carp (and
> therefore Exporter),
It would be even better if they didn't use autouse or any other *module*
solution and instead just delayed loading until the module was actually
needed. That's what I do with most of what I write and it works great for
keeping load times down, particularly with modules where a lot of the
functionality is never used in the common case.
Carp only gets called if there's an error. I don't care nearly as much
about how long it takes something to fail. It should never be loaded
unless something is failing.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Fri, 28 Aug 1998 04:56:17 GMT
From: sowmaster@juicepigs.com (Bob Trieger)
Subject: Re: newbie question
Message-Id: <6s5dfm$plv$2@ligarius.ultra.net>
No.unsoiliciteds@dead.end (Norman UNsoliciteds) wrote:
-> In article <obg1eib8rz.fsf@alder.dev.tivoli.com>, "Jim Woodgate"
-> <jdw@dev.tivoli.com> wrote:
->
-> > I have perl5 running on an NT box, both perl -de 42 and perldoc -f
-> > <your favorite command> work perfectly.
->
-> great what do they mean? (remember I don't have unix man pages so advice
-> like "grep man f(5)" isn't going to explain a lot :)
When are you just going to go away and stop proving the point that I am
trying to fight? IE.. most win32 user are morons. You've got to be the
2nd biggest ignoramous posting to c.l.p.m in months.
Bob Trieger
sowmaster@juicepigs.com
" Cost a spammer some cash: Call 1-800-400-1972
Ext: 1949 and let the jerk that answers know
that his toll free number was sent as spam. "
------------------------------
Date: Fri, 28 Aug 1998 17:25:47 +0900
From: No.unsoiliciteds@dead.end (Norman UNsoliciteds)
Subject: Re: newbie question
Message-Id: <No.unsoiliciteds-2808981725470001@cs11n47.ppp.infoweb.or.jp>
In article <6s5dfm$plv$2@ligarius.ultra.net>, sowmaster@juicepigs.com (Bob
Trieger) wrote:
> When are you just going to go away and stop proving the point that I am
> trying to fight? IE.. most win32 user are morons. You've got to be the
> 2nd biggest ignoramous posting to c.l.p.m in months.
and the first wouldn't be you would it, nice email BTW fits you
--
The Dinosaurs were so stupid, they couldn't
even devise the means of thier own extinction,
they had to wait for Nature to do it for them.
------------------------------
Date: Fri, 28 Aug 1998 17:48:01 +0900
From: No.unsoiliciteds@dead.end (Norman UNsoliciteds)
Subject: Re: newbie question
Message-Id: <No.unsoiliciteds-2808981748010001@cs11n47.ppp.infoweb.or.jp>
In article <1deg0qd.16y1tinps9q66N@bay2-134.quincy.ziplink.net>,
rjk@coos.dartmouth.edu (Ronald J Kimball) wrote:
> What do they have to do with unix manpages? perl -de 42 means run the
> script '42' in the debugger, as documented in perlrun. perldoc -f
> <command> means look up the documentation for a function, as explained
> in perldoc's usage function and builtin help.
> No unix manpages needed.
The perl -de I conceed (perldebug), but perldoc -f on the Mac port I'm
using turns up a blank if I grep for it - something which doesn't occur
for anything included in the contents of the docs which I do have which
I've listed below. None of them explain perl docs usage. I still don't
have a UN*x manual nor a Un*x Perl manual.
Docs bundled with MacPerl 5.004
perl Perl overview
perldelta Perl changes since previous version
perlfaq Perl frequently asked questions
perldata Perl data structures
perlsyn Perl syntax
perlop Perl operators and precedence
perlre Perl regular expressions
perlrun Perl execution and options
perlfunc Perl builtin functions
perlvar Perl predefined variables
perlsub Perl subroutines
perlmod Perl modules: how they work
perlmodlib Perl modules: how to write and use
perlform Perl formats
perllocale Perl locale support
perlref Perl references
perldsc Perl data structures intro
perllol Perl data structures: lists of lists
perltoot Perl OO tutorial
perlobj Perl objects
perltie Perl objects hidden behind simple variables
perlbot Perl OO tricks and examples
perlipc Perl interprocess communication
perldebug Perl debugging
perldiag Perl diagnostic messages
perlsec Perl security
perltrap Perl traps for the unwary
perlstyle Perl style guide
perlpod Perl plain old documentation
perlbook Perl book information
perlembed Perl ways to embed perl in your C or C++ application
perlapio Perl internal IO abstraction interface
perlxs Perl XS application programming interface
perlxstut Perl XS tutorial
perlguts Perl internal functions for those doing extensions
perlcall Perl calling conventions from C
--
The Dinosaurs were so stupid, they couldn't
even devise the means of thier own extinction,
they had to wait for Nature to do it for them.
------------------------------
Date: 28 Aug 1998 07:33:32 GMT
From: pra@pra.mint.se ()
Subject: Re: Perl compiler
Message-Id: <6s5mgc$83b$1@news.mint.se>
In article <6rt1jv$9fu$1@marina.cinenet.net>,
cberry@cinenet.net (Craig Berry) writes:
> Tom Christiansen (tchrist@mox.perl.com) wrote:
>: While you are
>: certainly under no obligation to do so, neither are we under any sort of
>: obligation to help you in your embarrassing pursuit of shameful hoarding.
>
> Oh, please. Turn the rhetoric nob back down to about 7, please, you're
> hurting my ears. :) Is a carpenter failing to give away tables and
> cabinets 'hoarding'? In your world, he'd give away the cabinets, then
> make his money off dropping by to maintain and polish them, and to point
> out hidden drawers the client might not have noticed. Different business
> model, that's all it is. Or don't you eat?
No, not just different business model, since your example in reality does not
cach the implication of sofware on the sociatal echonomy.
Let us bystep the fact that the carpenter put some time into making the table
(or a programmer making software) and let us also bystep the fact that he used
some tools (the programmer a computer) and then focus on the differens: the
carpenter need woods, and woods are a scarce resource - the programmer on the
other hand only needs his thougth (and the thougts of other).
To be more general: if I have a table and give it away to you, you have a table
but I don't. If I have a program and give it to you, you have a program, but so
do I.
Since Adam Smith the whole economic discussion (and the idea of a market
economy) has cirkled round the fact that resources are scarse. It is
around this axe that micro enconomics and demand-supplies curves has turned
since then. But - and this is to me the realy the fundamental question for
Open Source and whats makes it socialy rational - sofware brakes whith this
paradigm.
When the carpenter makes a table, he makes the world a litle richer. But when
he gives (or sells) it away he is just distributing this welth. When someone
makes a program he also makes the world richer, but when i gives it away he
doubles the welth because he still has the program.
Ok, I have to admit that the same would hold true even if he sold the
software. But, if he does not allow it to be reproduced for free he is in
fact hoarding, because he is trying to stop a rational behaviour in
this part of the economy.
>
>: I do not wish you luck, because I am morally opposed to the choice you
>: are attempting to make.
>
> I'll be interested to see the moral system that leads to this extreme a
> position...
Given a more correct analysis and not comparing with scarce resources it
turns out that Tom's stand on this is not that extreme, in fact it is in
par with the inner economics of sofware. And as such, it is not only a
question of "moral".
Peter
ps
Execuse my bad english, but I had to write this because it is so seldom stated
in discussions about Open source.
ds
--
--------------------------------------------------------
Peter Antman MARIEBERG INTERACTIVE AB
System Developer Box 27 205, 102 53 Sockholm
Epost: pra@mint.se WWW: http://www.mint.se/
Tel: 08-459 39 33 Fax: 08-661 51 30
--------------------------------------------------------
------------------------------
Date: Thu, 27 Aug 1998 23:37:06 -0700
From: "Dan Bassett" <dan@bns.com>
Subject: posting to a program, receiving results
Message-Id: <35e650ac.0@news1.starnetinc.com>
I am trying to write a perl program which will post variables to a program
and then
read back in the response from that program. The program is a binary
executable.
I can run the program from the prompt, but I just can't seem to make it work
within
perl.. Is this the correct way to execute a program within perl?
Here's what I have so far:
open (RESULTS, "program variable1 variable2" |")
or die "The program cannot be found.\n";
$status=<RESULTS>;
close RESULTS;
print "Here is the status: $status";
Any feedback would be apprecaited...
Regards,
Dan
dan@bns.com
------------------------------
Date: 28 Aug 1998 06:44:24 GMT
From: "Jim Babbington" <jwb79@mail.idt.net>
Subject: Re: Win32 and Perl
Message-Id: <01bdd24f$6ed6c460$6488fdc7@dixon>
: applications such as Excel through the OLE package on Perl. What about
: pulling up things such as dialog boxes, file browsers, etc for interactive
: use in scripts? Is it possible to do this? If so, could someone point me
: towards an online guide as to how to do this (with examples?)
So far, the TK package is your best bet (available at finer CPAN sites across the globe)
But you may want to keep an eye on GUI.pm, currently in Alpha. This module uses the
more native winders routines you would find in MS VC++.
TK Pluses - It will work on any platform that WISH will work.
GUI pluses - has a neat script to convert VB forms to perl (For those wishing to eraticate VB :-).
Happy hunting,
Jim
------------------------------
Date: Thu, 27 Aug 1998 21:58:34 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Y2K Date Support
Message-Id: <MPG.104fd8d147f100b998980f@nntp.hpl.hp.com>
In article <6s59lr$1kf$1@marina.cinenet.net> on 28 Aug 1998 03:54:34 GMT,
Craig Berry <cberry@cinenet.net> says...
...
> In effect, and for sufficient reasons, localtime (Unix/C/Perl lineage) uses
> a special calendar, identical to the common civil calendar in almost all
> respects [1] other than that is counts the year 0 as being what the civil
> calendar calls 1900.
...
> [1] The leapyear rule as usually formulated works on 'localtime year' +
> 1900 (or plus 300, if you extend the Gregorian calendar backward that
> far), rather than on raw 'localtime year' values. Another trivial
> difference is that localtime month indices start with January as 0, as
> opposed to the civil calendar convention of January being 1.
Well, there is another difference, other than in notation. As was
discussed here a while ago, every localtime year contains exactly 86400
seconds per day, whereas the civil calendar adds a leap second every so
often to account for the slowing of the rotation of the Earth. These
calendars thus now deviate by (IIRC) 29 seconds, which might actually
affect some applications. The solution is to declare the instantaneous
localtime or UTC correctly, and allow the Epoch to be off by half a
minute or so -- which is how computer clocks are actually set.
--
(Yet Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Thu, 27 Aug 1998 22:56:42 -0700
From: Mee <mee@mine.com>
Subject: Re: Y2K Date Support
Message-Id: <35E6469A.9D7E2AC9@mine.com>
Craig,
I was referring to the civil calendar in common use today as
the yardstick against which other calendars are to be measured.
Einstein did say "It is all relative", but for our purposes
within the observable space and foreseeable time,
our current calendar is "absolute" enough.
Obviously, the Perl's notion of time differs from the actual (human)
calendar (in more than just the year) -- and that is where Y2K-like
time-bombs lurk.
As for handling the potentially unsafe year answer in Perl
being a trivial thing, take a look at the latest Y2K-fix
cost estimates (which is/was also a trivial thing).
Thank you for proving my point about Perl and Y2K in the end
(in case you missed it, the challenge was to DISPROVE my statement).
Mee
------------------------------
Date: 27 Aug 1998 23:10:56 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Y2K Date Support
Message-Id: <m3soihprf3.fsf@windlord.Stanford.EDU>
Mee <mee@mine.com> writes:
> ANYTHING (including, forgive me the blasphemy, Perl) saying "the YEAR is
> 0" when referring to a year which is not "the YEAR 0" is bound to mess
> up something sooner or later.
Yup. Wholeheartedly agreed. I can't believe all those idiot almanac
publishers who keep referring to the year -1900 as the year 0. Do you
know how many budding Perl and C programmers they've hopelessly confused?
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: Fri, 28 Aug 1998 06:39:22 GMT
From: maurice@hevanet.com (Maurice Aubrey)
Subject: Re: Y2K Date Support
Message-Id: <slrn6uck4q.3eb.maurice@we-24-130-48-83.we.mediaone.net>
On Thu, 27 Aug 1998 22:56:42 -0700, Mee <mee@mine.com> wrote:
>Obviously, the Perl's notion of time differs from the actual (human)
> calendar (in more than just the year) -- and that is where Y2K-like
>time-bombs lurk.
>
>As for handling the potentially unsafe year answer in Perl
>being a trivial thing, take a look at the latest Y2K-fix
>cost estimates (which is/was also a trivial thing).
>
>Thank you for proving my point about Perl and Y2K in the end
>(in case you missed it, the challenge was to DISPROVE my statement).
But if you read the documentation and use the time related functions
as documented, they can all handle the new millenium without incident.
Are you saying that some people may not have read the documentation,
or may not have understood it, and that Perl, therefore, has a Y2K problem?
That's like saying Unix has a security problem because root can
do a 'rm -rf .*'.
If you write software without understanding how the functions work,
then you have a bigger problem than Y2K.
--
Maurice Aubrey <maurice@hevanet.com>
All of the books in the world contain no more information than is
broadcast as video in a single large American city in a single year.
Not all bits have equal value.
- Carl Sagan
------------------------------
Date: 28 Aug 1998 00:06:17 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Y2K Date Support
Message-Id: <m3hfyxpouu.fsf@windlord.Stanford.EDU>
Mee <mee@mine.com> writes:
> Obviously, the Perl's notion of time differs from the actual (human)
> calendar (in more than just the year) -- and that is where Y2K-like
> time-bombs lurk.
s/Perl/nearly all computers/. VMS uses modified Julian. Unix uses 1970
or 1900 depending on the context. Other platforms use other things.
There are good reasons for doing this; some of these calendars were in
wide use in some fields long before computers.
I'm a little skeptical of anyone who doesn't fully understand the
implications of leap seconds and the difference between UTC and TAI
timekeeping methods criticizing the implementation of a time system.
Which is why I generally try to just use what the system presents me with,
since I definitely *don't* fully understand those things. :)
Perl's use of time is as Y2K-compliant as most anything else, as it
returns sufficient information to disambiguate the century. Beyond that,
it's up to the programmer to know how to use their tools.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: 28 Aug 1998 06:59:25 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Y2K Date Support
Message-Id: <6s5kgd$ac9$1@marina.cinenet.net>
Mee (mee@mine.com) wrote:
: I was referring to the civil calendar in common use today as
: the yardstick against which other calendars are to be measured.
Ah, the sweet smell of cultural imperialism... :)
: Einstein did say "It is all relative", but for our purposes
: within the observable space and foreseeable time,
: our current calendar is "absolute" enough.
It's certainly a common, agreed-upon framework for most international
business and science...which is enough to make it very common, and
certainly the 'default calendar' for most purposes.
: Obviously, the Perl's notion of time differs from the actual (human)
: calendar (in more than just the year) -- and that is where Y2K-like
: time-bombs lurk.
Well, "Perl's notion of time" is really a 32-bit (or 64-bit on some
architectures, ISTR) signed integer type designated time_t. It counts
seconds, ignoring leap seconds, from Jan. 0 1970 (that is, the midnight
beginning Jan. 1). localtime() and friends are simply convenient front
ends for time_t. And any significant software project is going to involve
conversions between internal and human-visible data representations; such
go with the territory. That numerous programmers have done these
conversions wrong is a problem with human shortsightedness or stupidity,
not a problem with time_t or its family of functions. (The Y2038 bug, in
contrast, *is* a problem with time_t.)
: As for handling the potentially unsafe year answer in Perl
: being a trivial thing, take a look at the latest Y2K-fix
: cost estimates (which is/was also a trivial thing).
Humans show a distressing tendency to take even trivial challenges and
fail them miserably. Consider that all existing localtime-driven variants
on the more general y2k bug could have been solved by judicious use of
addition/subtraction of 1900 and %4d year print formats.
: Thank you for proving my point about Perl and Y2K in the end
: (in case you missed it, the challenge was to DISPROVE my statement).
I saw that, but I'm still at a loss to understand what your purpose was in
that paragraph.
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
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 3571
**************************************
