[11557] in Perl-Users-Digest
Perl-Users Digest, Issue: 5157 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 17 13:07:33 1999
Date: Wed, 17 Mar 99 10:00:17 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 17 Mar 1999 Volume: 8 Number: 5157
Today's topics:
data query <c-denman@dircon.co.uk>
Re: Days in Month array (Craig Berry)
Re: difference between my $x = 1 and my $x; $x = 1 <zenin@bawdycaste.org>
Re: DUMB Newbie question <jbc@shell2.la.best.com>
Re: Help on C-Kermit ... (Frank da Cruz)
Re: How do I split an list of text into separate lists <dropzone@mail.utexas.edu>
Re: How to call CORE::opendir() via AUTOLOAD()? <zenin@bawdycaste.org>
How to dup a $fh_ref ? <prlawrence@lehigh.edu>
Re: How to get a long filename from a shortened one? <Allan@due.net>
Re: How to get stack backtrace into a logfile <zenin@bawdycaste.org>
Re: How to get stack backtrace into a logfile <prlawrence@lehigh.edu>
Re: Incrementing several values in a hash <jdf@pobox.com>
need perl script to check if web sites are up <eyoung_3@earthlink.net>
Re: need perl script to check if web sites are up <Tony.Curtis@vcpc.univie.ac.at>
Re: Sendmail and Cc: field (brian d foy)
storing data the best way - question? <c-denman@dircon.co.uk>
Re: storing data the best way - question? (brian d foy)
Re: storing data the best way - question? (David Cantrell)
Re: storing data the best way - question? <c-denman@dircon.co.uk>
Re: storing data the best way - question? (Clinton Pierce)
Re: ternary operator <jglascoe@giss.nasa.gov>
Re: The truth about the Pentium III chip and ID --- **b <barnesm@cain-travel.com>
Very simple question (Barry)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 17 Mar 1999 16:46:35 -0800
From: "Chris Denman" <c-denman@dircon.co.uk>
Subject: data query
Message-Id: <36efdc17.0@glitch.nildram.co.uk>
The main question, I suppose, is would it be worth investing time and money
into learning how to use a new system when, fundimentally, the system I have
should suffice (lets presume that locking works, and there are regular
backups etc)
Is is quicker to use dbf, or other formats?
------------------------------
Date: Wed, 17 Mar 1999 17:58:01 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Days in Month array
Message-Id: <J2SH2.857$Vl4.25100@newsfeed.slurp.net>
Jay Glascoe (jglascoe@giss.nasa.gov) wrote:
: > I'm trying to build a timeline of days and dates when given a
: > year. Leap years are messin with my code.
: >
: > How does one calculate if a given year is a leap year?
:
: isn't it simply
:
: print "leap year\n" if $year % 4 == 0;
Nope.
my $isLeap = ($year % 4 == 0 &&
$year % 100 != 0) ||
$year % 400 == 0;
That is, a year is a leap year if:
* It is divisible by four, unless
* It is a century year, unless
* It is a 400-year multiple.
Putting it yet another way, every four years is a leap year, except
non-400-multiple century years. So 1996 and 2000 are leap years, but 1900
and 2100 are not.
--
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "It's not an optical illusion; it just looks like one."
------------------------------
Date: 17 Mar 1999 16:14:24 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: difference between my $x = 1 and my $x; $x = 1
Message-Id: <921687543.490135@thrush.omix.com>
Samuel Kilchenmann <skilchen@swissonline.ch> wrote:
: Where can i find a description of the semantic difference between
: a) my $x = something;
: and
: b) my $x; $x = something;
:
: Two more or less silly examples where the difference is evident. Both
: examples are using "anonymous" internal helper functions, which are called
: recursively.
>snip<
: my $next_perm; #predeclaration needed
: $next_perm = sub { # my $next_perm = sub { # DOESN'T WORK
>snip<
: &$next_perm($i + 1);
>snip<
: };
The scope of a lexical variable is from after it's declaration to
the end of its enclosing block. Thus, $next_perm is not in scope
until *after* the statement that declares $next_perm.
--
-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: 17 Mar 1999 17:48:04 GMT
From: John Callender <jbc@shell2.la.best.com>
Subject: Re: DUMB Newbie question
Message-Id: <36efead4$0$205@nntp1.ba.best.com>
Tad McClellan <tadmc@metronet.com> wrote:
> You have an error on line 17.
What Tad is trying to say is that you haven't supplied enough
information for an expert to be able to give a useful answer. Ideally,
you would have posted the offending Perl code, making it easy for this
group's regulars to point out where you went wrong.
Actually, I think you *did* supply enough information for an expert to
at least make a decent guess about what your problem is, and how you
might fix it, but most people with that much expertise are pretty anal
when it comes to dishing out advice: they abhor guessing, and want to
give the one (1) correct answer so they can get on with their long list
of much more important (or at least much more interesting) problems
they need to solve. Giving a partial answer, requesting more
information, possibly even getting involved in an ongoing *dialog* with
the hapless newbie; these sorts of things give them hives.
Lost on many of these experts is the irony inherent in their apparent
belief that someone clueless enough to ask this sort of question will
nevertheless be clueful enough to ask it in the way that they, by
virtue of their expertise, deem to be appropriate.
Tad's response in this case illustrates another too-common (in my view,
at least) aspect of the expert mindset: Instead of just ignoring you,
or telling you in newbie-friendly language that you needed to supply
more info, he responded in a way that sacrificed intelligibility on
your part for enhanced entertainment value in the eyes of other
experts.
This sort of response almost always rubs me the wrong way. Presumably
this is because I'm not terribly expert myself, and tend to identify
with newbies more than with those who make fun of them. (In fairness,
Tad's response was fairly tame as an example of newbie-baiting. I'm
just overly sensitive.)
We can now look forward to several followups in which Tad's approach is
defended by other experts as being just the sort of "tough love" that
newbies need if they're ever going to learn.
Sigh.
--
John Callender
jbc@west.net
http://www.west.net/~jbc/
------------------------------
Date: 17 Mar 1999 16:35:43 GMT
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Help on C-Kermit ...
Message-Id: <7colkv$7nu$1@newsmaster.cc.columbia.edu>
In article <36EF3D5F.476665CC@tyr.mty.itesm.mx>,
Victor Acevedo <vacevedo@tyr.mty.itesm.mx> wrote:
: I have a problem , I'm using C-Kermit to make a phone connection, but I
: can't configure my modem properly, I think the problem is related to the
: assignation of the port .. Any idea ?
:
What commands did you give? What error messages did you get?
What version of C-Kermit do you have? On what hardware, OS, and version?
What kind of modem?
See:
http://www.columbia.edu/kermit/ckermit.html
for information about C-Kermit: the latest version, documentation, how to
get support, etc.
- Frank
------------------------------
Date: Wed, 17 Mar 1999 10:38:00 -0600
From: Forrest Reynolds <dropzone@mail.utexas.edu>
Subject: Re: How do I split an list of text into separate lists of paragraphs
Message-Id: <36EFDA69.C0866072@mail.utexas.edu>
Hello,
You can switch from processing lines to processing paragraphs by setting $/:
local $/ = ''; #sets itself back when you're done
This is explained in the Perl Cookbook p.282,
also perlvar(1), "special variables" chap2-camel.
Hope this helps, Forrest
Jim Britain wrote:
>
> There's got to be a better way to break text to paragraphs..
> However, I would still like to know how to separate paragraphs to an
> individual (indexed) list of paragraphs.. (without going more nuts).
------------------------------
Date: 17 Mar 1999 16:00:51 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: How to call CORE::opendir() via AUTOLOAD()?
Message-Id: <921686731.66055@thrush.omix.com>
[posted & mailed]
Hr. Jochen Stenzel <Jochen.Stenzel.gp@icn.siemens.de> wrote:
: <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
>snip<
DO NOT POST HTML TO USENET, *EVER*!!!!!!! Thanks. :-)
>snip<
: This code fails if opendir() is called, the eval() result trace displays
: "Not enough arguments for opendir at (eval 16) line 1". If I remove
: "opendir" from the "use subs" list, the final opendir() call works.
Your code is calling "CORE::opendir(@_)". opendir() is not
prototyped to take an array argument. You can see this with
simply:
$ perl -wce 'opendir(@foo)'
Not enough arguments for opendir at -e line 1, at end of line
-e had compilation errors.
Change your eval() to:
eval "my \$rc=CORE::$function($_[0], '$_[1]')";
--
-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: Wed, 17 Mar 1999 11:02:54 -0500
From: "Phil R Lawrence" <prlawrence@lehigh.edu>
Subject: How to dup a $fh_ref ?
Message-Id: <7cojnl$14jk@fidoii.cc.Lehigh.EDU>
OK, I want to redirect STDERR. The following test script works fine if I
redirect to LOG, but dies if I try to redirect to $fh_log. How should I do it?
_______________________
#!/usr/local/bin/perl -w
use diagnostics;
open LOG, ">test.log" or die "Couldn't open log!";
$fh = \*LOG;
open SAVERR, ">&STDERR";
open STDERR, ">&$fh" or die "Couldn't redirect STDERR!";
select( (select(STDERR), $| = 1)[0] ); # Make unbuffered
sub a {
b(@_);
}
sub b {
print @_, "\n";
die "test death";
}
a('test');
close STDERR;
open STDERR, ">&SAVERR" or die "Couldn't restore STDERR!";
___________________
--
Phil R Lawrence
Lehigh University
Enterprise Systems Implementation
Programmer / Analyst
prlawrence@lehigh.edu - work
prlawrence@planetall.com - personal
------------------------------
Date: Wed, 17 Mar 1999 12:09:38 -0500
From: "Allan M. Due" <Allan@due.net>
Subject: Re: How to get a long filename from a shortened one?
Message-Id: <7con7f$905$1@samsara0.mindspring.com>
Sean Phillips wrote in message <36EF203C.226210D4@bit-net.com>...
:Windows NT/Perl question:
:When you drag-n-drop a file onto a Perl program on the desktop the OS
:feeds the filename to $ARGV[0]. Unfortunately, it will use the short
:(8.3) filename.
:Is there any way to translate it back to the long filename?
:
:I've tried a pipe from the command "dir /N $shortfilename" and while
:that fixes the filename itself, the directory is still mangled. The
:utilities in Cwd don't seem to help either.
Well, here is what I have come up with. I am not sure why there is a
GetShortPathName but not a GetLongPathName. I am not sure it would ever
make a difference in this situations if you were to use the eq vs the match.
I include them both in case it is helpful. You would need to make sure that
@files only has one element, if there are multiple matches obviously
something has gone wrong <g>.
#!/usr/local/bin/perl -w
use strict;
use Win32;
use File::Basename;
my $fullname = shift @ARGV;
my ($name,$path) = fileparse($fullname);
opendir (DIR,"$path") or warn "$!\n";
#@files = grep {Win32::GetShortPathName("$path$_") =~ /$name/i}
readdir(DIR);
my @files = grep {Win32::GetShortPathName("$path$_") eq $fullname}
readdir(DIR);
close (DIR);
HTH
AmD
--
$email{'Allan M. Due'} = ' All@n.Due.net ';
--random quote --
People get annoyed when you try to debug them.
- Larry Wall
------------------------------
Date: 17 Mar 1999 16:06:36 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: How to get stack backtrace into a logfile
Message-Id: <921687075.945032@thrush.omix.com>
[posted & mailed]
Phil R Lawrence <prlawrence@lehigh.edu> wrote:
: I like all the info that spills out when I die() with use diagnostics. I read
: that Carp->confess() does something similiar. However, I don't want to have all
: that info going to STDERR, just to a logfile.
:
: How can I get to the backtrace info so i can dump it into the logfile and not
: have it display on the screen?
Cheat a little:
use Carp ();
print MY_LOG_FILE Carp::longmess();
If you're afraid of longmess() going away (it's not documented, so
it could) then simply copy the Carp.pm code to someplace convenient
in your app.
--
-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: Wed, 17 Mar 1999 12:06:48 -0500
From: "Phil R Lawrence" <prlawrence@lehigh.edu>
Subject: Re: How to get stack backtrace into a logfile
Message-Id: <7conft$1d32@fidoii.cc.Lehigh.EDU>
>: How can I get to the backtrace info so i can dump it into the logfile and not
>: have it display on the screen?
> use Carp ();
> print MY_LOG_FILE Carp::longmess();
>
> If you're afraid of longmess() going away (it's not documented, so
> it could) then simply copy the Carp.pm code to someplace convenient
> in your app.
That does scare me, and I'm morally opposed to code duplication. :)
I tried the following and it seems pretty cool:
sub dielog {
my $self = shift;
if (my $log_fh = $self->{private_Report_info}{logref}) {
eval { confess @_ };
print $log_fh $@;
}
die @_;
}
Thanks again,
Phil
------------------------------
Date: 17 Mar 1999 11:21:21 -0500
From: Jonathan Feinberg <jdf@pobox.com>
To: blade@leela.janton.fi (Sami Rosenblad)
Subject: Re: Incrementing several values in a hash
Message-Id: <m3ww0grsse.fsf@joshua.panix.com>
blade@leela.janton.fi (Sami Rosenblad) writes:
> In article <w%uH2.11825$Ge3.46473337@news.itd.umich.edu>,
> mcafee@waits.facilities.med.umich.edu (Sean McAfee) wrote:
> > $hash{$_}++ foreach @keys;
>
> for (@keys) { $hash{$_}++ } # isn't this equivalent?
>
> foreach, modifier statements or not, still steps through the array,
> doesn't it? How does it differ from:
>
> map {$hash{$_}++} @keys; # sorry, map in void context :)
It differs in precisely the way which you suggest: the latter builds a
list and throws it away; the former does not.
--
Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf
------------------------------
Date: Wed, 17 Mar 1999 08:50:07 -0800
From: Ed Young <eyoung_3@earthlink.net>
Subject: need perl script to check if web sites are up
Message-Id: <36EFDD3E.5F8DCA32@earthlink.net>
I would appreciate an example of a script that will check if certain web
sites are
still functioning, thanks in advance.
eyoung@osius.com
------------------------------
Date: 17 Mar 1999 18:56:23 +0100
From: Tony Curtis <Tony.Curtis@vcpc.univie.ac.at>
Subject: Re: need perl script to check if web sites are up
Message-Id: <83g1746lvc.fsf@vcpc.univie.ac.at>
Re: need perl script to check if web sites are up,
Ed <eyoung_3@earthlink.net> said:
Ed> I would appreciate an example of a script that
Ed> will check if certain web sites are still
Ed> functioning, thanks in advance.
Depends on what you mean by "functioning". This
could mean any subset of
host pingable
HTTP server answers
HTTP request for specific path does what you expect.
The LWP modules are probably what you want,
perldoc LWP || http://www.cpan.org/
hth
tony
--
Tony Curtis, Systems Manager, VCPC, | Tel +43 1 310 93 96 - 12; Fax - 13
Liechtensteinstrasse 22, A-1090 Wien. | <URI:http://www.vcpc.univie.ac.at/>
"You see? You see? Your stupid minds! | private email:
Stupid! Stupid!" ~ Eros, Plan9 fOS.| <URI:mailto:tony_curtis32@hotmail.com>
------------------------------
Date: Wed, 17 Mar 1999 11:46:33 -0500
From: comdog@computerdog.com (brian d foy)
Subject: Re: Sendmail and Cc: field
Message-Id: <comdog-ya02408000R1703991146330001@news.panix.com>
In article <7cmere$skr$4@bison.rosnet.ru>, "Michael Yevdokimov" <flanker@sonnet.ru> posted:
> Some time ago I made a similar script. Instead of using Cc: I was including
> each person into To: field using foreach{} construction.
that is really annoying. Cc: is just like To: in terms of delivery,
but not so in terms of filtering and indexing (and reading) mail.
don't solve technical problems by taking shortcuts that annoy the
users.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
------------------------------
Date: Wed, 17 Mar 1999 16:16:05 -0800
From: "Chris Denman" <c-denman@dircon.co.uk>
Subject: storing data the best way - question?
Message-Id: <36efd545.0@glitch.nildram.co.uk>
Why would it not be a good idea to store records in the following way? I
use directories to store many records in a logical way, like so:
d:\data
d:\data\men
d:\data\men\under50\
d:\data\men\over50\
and a record could look like this-
the file '1.dat' could contain:
name:fred\n
age:55\n
sex:male\n
comments:This is a guy the age of 55, ect\n
The reason I ask is a few people have said that I should really use SQL,
ODBC and all that jazz - cos it's safer and so on.
I beleive that if you have one large file and access this over and over with
simultaneous users, when there's trouble the lot goes. With individual
records, at least only one record could get corrupted. (I could be talking
out of my arse, though!)
Do I?
The code I have retrieves this data extremely fast - I use a hash array and
a split to pull in each record.
I would appreciate comments on this one, ta
Chris D
------------------------------
Date: Wed, 17 Mar 1999 11:49:39 -0500
From: comdog@computerdog.com (brian d foy)
Subject: Re: storing data the best way - question?
Message-Id: <comdog-ya02408000R1703991149390001@news.panix.com>
In article <36efd545.0@glitch.nildram.co.uk>, "Chris Denman" <c-denman@dircon.co.uk> posted:
> Why would it not be a good idea to store records in the following way? I
> use directories to store many records in a logical way, like so:
>
> d:\data
> d:\data\men
> d:\data\men\under50\
> d:\data\men\over50\
>
> and a record could look like this-
>
> the file '1.dat' could contain:
>
> name:fred\n
> age:55\n
> sex:male\n
> comments:This is a guy the age of 55, ect\n
>
> The reason I ask is a few people have said that I should really use SQL,
> ODBC and all that jazz - cos it's safer and so on.
>
> I beleive that if you have one large file and access this over and over with
> simultaneous users, when there's trouble the lot goes.
backups are good. good databases don't have the problem you describe,
but perhaps you are using a product that crashes quite a bit on a
system that needs to be rebooted every three hours. those things tend
to cause file system irregularities.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
------------------------------
Date: Wed, 17 Mar 1999 16:52:14 GMT
From: NukeEmUp@ThePentagon.com (David Cantrell)
Subject: Re: storing data the best way - question?
Message-Id: <36f6dcaf.84574111@thunder>
On Wed, 17 Mar 1999 16:16:05 -0800, "Chris Denman"
<c-denman@dircon.co.uk> enlightened us thusly:
>Why would it not be a good idea to store records in the following way? I
>use directories to store many records in a logical way, like so:
>
>d:\data
>d:\data\men
>d:\data\men\under50\
>d:\data\men\over50\
>
>The reason I ask is a few people have said that I should really use SQL,
>ODBC and all that jazz - cos it's safer and so on.
Consider what happens if three people try to read the same datum at
the same time as seven people try to write it. Also consider how you
would keep track of the relationship between these men and their
favourite meal, and between them and their SOs, and how you would
guarantee that the integrity of those links was maintained even if
your server crashed halfway through a database update.
>I beleive that if you have one large file and access this over and over with
>simultaneous users, when there's trouble the lot goes. With individual
>records, at least only one record could get corrupted. (I could be talking
>out of my arse, though!)
Not necessarily - it depends on your application. If you're a club
secretary keeping people's membership records then your solution will
probably be adequate. But if you're keeping track of a hundred
million insurance policies, claim histories, and so on, then you're
stuffed.
Not to mention that a module like MySQL.pm will make your code more
readable, more reliable, and quite probably faster.
[Copying newsgroup posts to me by mail is considered rude]
--
David Cantrell, part-time Unix/perl/SQL/java techie
full-time chef/musician/homebrewer
http://www.ThePentagon.com/NukeEmUp
------------------------------
Date: Wed, 17 Mar 1999 17:02:07 -0800
From: "Chris Denman" <c-denman@dircon.co.uk>
Subject: Re: storing data the best way - question?
Message-Id: <36efdfc4.0@glitch.nildram.co.uk>
The re-post was a complete accident - cheers for the advice, though.
Chris D
------------------------------
Date: Wed, 17 Mar 1999 16:52:02 GMT
From: cpierce1@ford.com (Clinton Pierce)
Subject: Re: storing data the best way - question?
Message-Id: <36efda35.607994089@news.ford.com>
[author cc'd in E-Mail]
On Wed, 17 Mar 1999 16:16:05 -0800, "Chris Denman" <c-denman@dircon.co.uk>
wrote:
>Why would it not be a good idea to store records in the following way? I
>use directories to store many records in a logical way, like so:
>
>d:\data
>d:\data\men
>d:\data\men\under50\
>d:\data\men\over50\
This method has a lot of advantages over SQL, and DB format that sometimes
get overlooked. If it works for you, it works for you. Some things you
did not mention:
Good: frightfully easy to debug. Are there any "men over 50" records?
"dir d:\data\men\over50\". It's possible to browse your database with the
Windows Explorer.
Bad: Exceedingly expensive and somewhat obscure to get sequential access
to all of the data. (use File::Find, and open all the files and all of
the directories under data.)
Good: Editing the data is quite easy. "edit d:\data\men\under50\1.dat",
or "rmtree d:\data\women\harlots".
Bad: namespace for keys under each category is limited. Numbering them
introduces problems (holes, and finding the next in sequence).
Good: This method is very portable between architectures, and relies on no
external or purchased libraries.
Bad: complex queries ("all men over 50 with the name 'Fred'") are hard on
the OS...lots of files to be opened/read/closed.
Good: This scales quite well for random reads and random writes. Your
limits become the number of i-nodes (directory entries) in a filesystem,
the number of files allowed in a directory, and the OS's time to open
large directories. Netscape and IE both use this scheme to maintain their
cache databases. Then again, they know that there is a reasonable
upper-limit to the number and size of things they're going to be storing.
Bad: Large numbers of small (< disk cluster size) files waste space on the
disk. Lots of it after a while.
In other words, it's up to you. I wouldn't do this for anything you want
to scale to extremely large numbers, or anything that will require complex
queries.
If you're going to do this, wrap up the database reads/writes into a SMALL
set of functions that generate the keys (pathnames) and will spit out the
data appropriately. This way, if you ever want to switch databases and
use something more mainstream, you only have to fix those small functions.
Clinton A. Pierce "If you rush a Miracle Man, you get rotten
clintp@geeksalad.org Miracles." -- Miracle Max, The Princess Bride
http://www.geeksalad.org
------------------------------
Date: Wed, 17 Mar 1999 11:02:02 -0500
From: Jay Glascoe <jglascoe@giss.nasa.gov>
To: 23_skidoo@geocities.com
Subject: Re: ternary operator
Message-Id: <36EFD1FA.DB41ABBD@giss.nasa.gov>
[courtesy copy of post sent to cited author]
23_skidoo wrote:
>
<snip>
> $secondVar = ($firstVar == 0) ? 0 : $array[0];
[versus]
> $secondVar = $firstVar ? $array[0] : 0;
The top one works in cases where "$firstVar" is
either null, "", or undefined. So, if you're sure
"$firstVar" contains a number, then go ahead and
use the second line. Or, do something like
$secondVar = $firstVar || $array[0]; # probably best style
$secondVar = $firstVar or $secondVar = $array[0]; # a bit silly
$secondVar = $array[0] unless $secondVar = $firstVar; # sillier still
or, silliest of all ;^)
if ($firstVar) { $secondVar = $array[0] } else { $secondVar = $firstVar }
> been unable to find a reference for ternary in the perlfaq. does it go
> by any other names or can someone point me to a reference?
perldoc perlop, under "Conditional Operator"
Jay Glascoe
--
http://www.giss.nasa.gov/cgi-bin/csci/change.pl
------------------------------
Date: Wed, 17 Mar 1999 10:20:04 -0700
From: "Michael Barnes" <barnesm@cain-travel.com>
Subject: Re: The truth about the Pentium III chip and ID --- **boycott info**
Message-Id: <36efc6e7.0@news.webaccess.net>
Every MODEM has a MAC address also...so your friends pc is nicless, but not
macless
As far as I know you cannot network anywhere without a mac address since
IP's map directly to machine addresses at lower levels to identify your
particular machine on any network. So, if your connected to any network via
any hardware device (router, switch, modem, nic) those devices must have mac
addresses.
and modems are easy to replace compared to CPU's also...
Bill Anderson wrote in message <36EEB3DB.779FD60D@boi.hp.com>...
>Tim Roberts wrote:
>>
>> John Lehmann <johnl@axis.com.au> wrote:
>>
>> >Kano wrote:
>> >>
>> >> Oh come on. Many other standard devices (ethernet cards, for example)
>> >> have their
>> >> own unique serial numbers that software can use at will. Get over it.
>> >>
>> >
>> >Yes - but ethernet mac cards are only broadcast over the lan, not over
>> >the net (except by Office98, of course).
>>
>> The POINT here is that it is exactly as easy to embed my unique MAC
address
>> in an Internet transaction as it is to embed my unique Pentium-III CPU ID
>> in an Internet transaction. Any software which will go to the trouble to
>> fetch the unique CPU identifier and send it over the network to identify
me
>> could just as easily be written TODAY to use a MAC address for exactly
the
>> same purpose. The CPU identifier is not significantly different in
concept
>> from the MAC address, and yet there has not been a hue and cry to boycott
>> NIC manufacturers.
>
>Ho wmany home users ar LAN connected to the internet?
>oh, yeah, that's right, they dial up with a modem; no getting a MAC
>address from a machine that does not have one.
>
>>
>> >And what do you mean get over it??? This kind of personal information
>> >is valuable. Business are willing to pay for it. This kind of
>> >behavior IS DOWNRIGHT THEFT!!!
>>
>> But whatever they could do with a CPU ID, they are probably already doing
>> with a MAC address. It is just as good as a unique identifier. "Get
over
>> it" is exactly the right attitude.
>
>Can you explain how they would be getting a MAC address from my friends'
>NIC-less pc?
>
>A MAC address is not as good, in any event. NICs get changed mor often
>than cpus (in most cases). IIRC MAC addresses can be changed, and there
>have been cases of MAC addresses beinf reused?
------------------------------
Date: Wed, 17 Mar 1999 08:52:02 -0800
From: santobro@gis.net (Barry)
Subject: Very simple question
Message-Id: <h6RH2.9140$EF1.42635224@WReNphoon1>
please answer this very simple perl question.
this line reads a file into my perl script.
open(FILE,"file.txt") || die;
how do I read the file if its in a different directory? Lets say the one
above it.
open(FILE,"/file.txt") || die; this doesn't work.
open(FILE,"..file.txt") || die; this doesnt work either.
please help.
I'm trying to test these scripts on my ISP's server if that matters.
*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***
------------------------------
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 5157
**************************************
