[16829] in Perl-Users-Digest
Perl-Users Digest, Issue: 4241 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Sep 6 18:20:46 2000
Date: Wed, 6 Sep 2000 15:20:32 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <968278832-v9-i4241@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 6 Sep 2000 Volume: 9 Number: 4241
Today's topics:
Re: Reading a remote file. brian.russo@nextel.com
Re: Remove carriage returns from input <brondsem@my-deja.com>
Re: Stable sorting <lr@hpl.hp.com>
Re: Stable sorting (Abigail)
Re: Stable sorting <russ_jones@rac.ray.com>
Re: Stable sorting <uri@sysarch.com>
Re: Stable sorting <bart.lateur@skynet.be>
Re: Stable sorting <uri@sysarch.com>
Re: uninitialized value - but I have initilised it! Hav <linux@wizdom.org.uk>
unpack and Solaris acct struct (Matt Knecht)
Re: unpack and Solaris acct struct <uri@sysarch.com>
Re: unpack and Solaris acct struct (Matt Knecht)
Re: use strict: why? <gellyfish@gellyfish.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 06 Sep 2000 21:30:05 GMT
From: brian.russo@nextel.com
Subject: Re: Reading a remote file.
Message-Id: <8p6d01$hjq$1@nnrp1.deja.com>
Thanks, I'll try them both out.
-Brian
In article <G0FL4p.BtK@news.boeing.com>,
ced@bcstec.ca.boeing.com (Charles DeRykus) wrote:
> In article <u9g0ne4wdv.fsf@wcl-l.bham.ac.uk>, <nobull@mail.com>
wrote:
> >brian.russo@nextel.com writes:
> >
> >> Does anyone know if there is a module or technique available which
will
> >> allow me to open a file for READ only on a remote UNIX system. I
would
> >> like to avoid NFS mounting the filesystem or physically copying the
file
> >> to my local box.
> >
> >The obvious candidate is Net::FTP.
> >
>
> Another option is Net::Telnet. You can either slurp the
> remote file into memory all at once or set the remote
> terminal to raw mode and get a block at a time. There're
> examples of both in the docs.
>
> --
> Charles DeRykus
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 06 Sep 2000 19:03:12 GMT
From: Dave Brondsema <brondsem@my-deja.com>
Subject: Re: Remove carriage returns from input
Message-Id: <8p64d1$6rn$1@nnrp1.deja.com>
In article <Pine.GHP.4.21.0009061201060.8800-100000@hpplus03.cern.ch>,
"Alan J. Flavell" <flavell@mail.cern.ch> wrote:
> On Wed, 6 Sep 2000, Dave Brondsema wrote:
>
> > \r is return (ascii 13)
> > \n is newline (ascii 10)
>
> Take a read of perldoc perlport, and some of the useful contributions
> to this thread by other usenauts. I'd say you have something to learn
> about portability.
>
> > This simple answer was the result of a ~2 hr frustrating search.
>
> What? Perl nowadays comes with plenty of documentation. Familiarise
> yourself with it; use it.
I have plenty at hand (I normally use perl.com), but I can't just
ask "How do I get rid of multiple lines from a <textarea> result?" and
get the answer I need.
>
>
--
Dave Brondsema
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 6 Sep 2000 11:41:56 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Stable sorting
Message-Id: <MPG.14202fcd3623ca1d98ad28@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <x73djemr92.fsf@home.sysarch.com> on Tue, 05 Sep 2000
22:02:50 GMT, Uri Guttman <uri@sysarch.com> says...
...
> @sorted_inds =
> map unpack( 'x4N' ),
> sort
> map pack( 'NN', $records[$_][3], $_ ), 0 .. $#records ;
Um, err, gosh. Isn't that unpack() missing something?
> check out our paper at:
>
> http://www.hpl.hp.com/personal/Larry_Rosler/sort/sorting.html
Good idea! :-)
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 06 Sep 2000 15:09:21 EDT
From: abigail@foad.org (Abigail)
Subject: Re: Stable sorting
Message-Id: <slrn8rd5h5.tjm.abigail@alexandra.foad.org>
Russ Jones (russ_jones@rac.ray.com) wrote on MMDLXIII September MCMXCIII
in <URL:news:39B678B4.EA829997@rac.ray.com>:
:} Abigail wrote:
:} >
:} > ?? I'd hope that any implementation of "sort" in Perl would not preserve
:} > ?? the order of equally keyed records by default, although I'd like to
:} > ?? see it as an option. In most cases, though, it would be a solution
:} > ?? looking for a problem that just didn't exist.
:} >
:} > What an absurd requirement. If you don't want to preserve order, shuffle
:} > your data first. It's a trivial exercise to prove that merge sort is stable.
:} > No additional processing required.
:} >
:}
:} You just don't get it, do you?
:}
:} I don't dispute that merge sort is "stable." I don't actually know
:} that it is, but if you say so, I'm prepared to believe you. I don't
:} care how trivial it is to prove it. If you say it's so, that's enough
:} proof for me.
:}
:} It IS absurd, though, and a bit insulting, for you to think that I
:} have a requirement that equally keyed records MUST NOT be in the same
:} order as they were in the original file. I just don't usually care
:} what order they end up in, as long as they are properly sorted by
:} their sort key(s). It just doesn't matter, in nearly all applications.
Then why do you want the ability to turn off stability?
:} But is merge sort more efficient sorting a file with a large number of
:} equally keyed records than some other sort that doesn't have to keep
:} those records in their original order? Why spend the cycles doing the
:} extra ordering for every one of your sorts when it's rarely needed?
:} Why not just turn that feature on when you need it?
*You* just don't get it, do you? Merge sort *is* stable. It isn't a matter
of spending extra cycles doing extra ordering. In fact, it saves cycles
not swapping things out of order. Stability comes with the algorithm,
free of charge.
But it wasn't that stability was the reason quick sort got replaced by
merge sort. Benchmarks has shown that in most cases, merge sort needs
less comparisons than quick sort, that it's generally faster (it loses
when there are many duplicates though), in common cases (sorted or nearly
sorted data) it's noticebly faster, and, non the least important, it's
garenteed to be O (n log n) (compared to quick sorts quadratic worst
case behaviour). Stability was just an extra added bonus.
:} There is no one-size-fits-all sort. I'll grant that for most of the
:} sorts that I've seen implemented from inside a Perl script, it really
:} doesn't matter which sort you use, as long as your data gets sorted.
:} But on really big sorts, where you're sorting many billions of records
:} on multiple ascending and descending keys, the sorting algorithm your
:} program uses can make a significant difference in the resources
:} required, and artificially ordering records that didn't need to be
:} ordered in the first place is a waste of resources.
Of coure. But it takes one hell of machine to create a Perl list
containing billions of records, let alone sort it. We aren't discussing
the merits of sorting in general. We should keep in mind that the sort
will use on Perl lists, and hence memory usuage is already high to
begin with.
You also might want to catch up on recent p5p discussions. (BTW, a pragma
to swap sorting routines might be there in 5.8).
And I strongly suggest to read Knuth, or another standard textbook
discussing various sorting routines.
Abigail
--
# Perl 5.6.0 broke this.
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
------------------------------
Date: Wed, 06 Sep 2000 14:30:45 -0500
From: Russ Jones <russ_jones@rac.ray.com>
Subject: Re: Stable sorting
Message-Id: <39B69B65.59E1AFFF@rac.ray.com>
Abigail wrote:
>
Who cares at this point.
I retire the field. You're just too good for me. You can be the
sorting queen.
--
Russ Jones - HP OpenView IT/Operatons support
Raytheon Aircraft Company, Wichita KS
russ_jones@rac.ray.com 316-676-0747
Quae narravi, nullo modo negabo. - Catullus
------------------------------
Date: Wed, 06 Sep 2000 19:56:49 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stable sorting
Message-Id: <x7vgw9jnun.fsf@home.sysarch.com>
>>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
>> @sorted_inds =
>> map unpack( 'x4N' ),
>> sort
>> map pack( 'NN', $records[$_][3], $_ ), 0 .. $#records ;
LR> Um, err, gosh. Isn't that unpack() missing something?
blarg! forgot the $_.
>> check out our paper at:
LR> Good idea! :-)
hey maybe i can learn something from it!
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Wed, 06 Sep 2000 21:21:13 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Stable sorting
Message-Id: <62ddrsscnp5nvdko3gj3hdv61r711o488i@4ax.com>
Uri Guttman wrote:
> @sorted_inds =
> map unpack( 'x4N' ),
> sort
> map pack( 'NN', $records[$_][3], $_ ), 0 .. $#records ;
Too bad that the field I want to sort to, is a floating point number.
I'm not sure what relation there is between numerical comparison and
string comparision and the packed float, but it's signed (ugh), only
available in native format (endianness? Ugh ugh) and I don't know what
number of bytes it takes. Or: no can do.
--
Bart.
------------------------------
Date: Wed, 06 Sep 2000 21:27:32 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Stable sorting
Message-Id: <x7hf7tjjng.fsf@home.sysarch.com>
>>>>> "BL" == Bart Lateur <bart.lateur@skynet.be> writes:
BL> Uri Guttman wrote:
>> @sorted_inds =
>> map unpack( 'x4N' ),
>> sort
>> map pack( 'NN', $records[$_][3], $_ ), 0 .. $#records ;
BL> Too bad that the field I want to sort to, is a floating point number.
BL> I'm not sure what relation there is between numerical comparison and
BL> string comparision and the packed float, but it's signed (ugh), only
BL> available in native format (endianness? Ugh ugh) and I don't know what
BL> number of bytes it takes. Or: no can do.
well, you didn't state the field type before. larry has shown ways to
sort floats as long as they are in ieee format which is true for almost
all common cpus today. i have not played with that but he could help
you. i think you would use the d format and that would work. ieee floats
are designed to compare directly as byte strings.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Wed, 6 Sep 2000 19:35:06 +0100
From: Mark Worsdall <linux@wizdom.org.uk>
Subject: Re: uninitialized value - but I have initilised it! Haven't I?
Message-Id: <01jR6IAa5ot5EwQK@worsdall.demon.co.uk>
In article <39B5AAF2.E36E7235@ipac.caltech.edu>, Tim Conrow
<tim@ipac.caltech.edu> writes
>Mark Worsdall wrote:
>>
>> Why do I get this error:-
>>
>> Use of uninitialized value at /usr/www/cgi-bin/DisplayAgents.pl line 57.
>>
>> Line 57: @pairs = split(/&/, $ENV{'QUERY_STRING'});
>>
>
>Well, since @pairs is initialized, what other variable in that statement might
>not be? Besides, since @pairs is in the receiving side of the '=', it doesn't
>matter if it's initialized, only that it's declared.
>
>Also: you're working way too hard doing intializations on all those other
>variables. You're better off simply testing where neceesary for definedness.
>
>perldoc -f defined
>
read that.
So do this instead?
my $name = '';
my $value = '';
my $pair = '';
my @pairs = ();
my $buffer = '';
if ($ENV{'REQUEST_METHOD'} eq 'GET') {
# Split the name-value pairs
if defined $ENV{'QUERY_STRING'} {
@pairs = split(/&/, $ENV{'QUERY_STRING'});
}
}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST') {
# Get the input
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
# Split the name-value pairs
@pairs = split(/&/, $buffer);
}
else {
exit;
}
--
He came from Econet - Oh no, I've run out of underpants :(
Home:- jaydee@wizdom.org.uk http://www.wizdom.org.uk
Shadow:- webmaster@shadow.org.uk http://www.shadow.org.uk
Work:- netman@hinwick.demon.co.uk http://www.hinwick.demon.co.uk
Web site Monitoring:- http://www.shadow.org.uk/SiteSight/
------------------------------
Date: Wed, 06 Sep 2000 20:23:13 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: unpack and Solaris acct struct
Message-Id: <RIxt5.804$3v3.36835@news2.voicenet.com>
I'm trying to upack a pacct file generated by Solaris' accounting
tools. According to <sys/acct.h>, a struct of acct has the following
format:
# struct acct
# {
# char ac_flag;
# char ac_stat;
# uid_t ac_uid;
# gid_t ac_gid;
# dev_t ac_tty;
# time_t ac_btime;
# comp_t ac_utime;
# comp_t ac_stime;
# comp_t ac_etime;
# comp_t ac_mem;
# comp_t ac_io;
# comp_t ac_rw;
# char ac_comm[8];
# };
Where according to <sys/types.h> :
uid_t == long
gid_t == long
dev_t == unsigned long
time_t == int
comp_t == unsigned short
I'm using the following format to unpack:
my $unpack_fmt = "ccllLiSSSSSSA*";
sysread F, $buf, 40;
my @s = unpack $unpack_fmt, $buf;
unpacking yields two extra bytes (Usually NULL, but not always)
prepended to ac_comm. The acct structs are coming from Solaris 2.6,
and I'm crunching the data on a Linux box. I've "duplicated" the acct
struct in C on Linux, and I don't see these extra two bytes.
Any thoughts about what I'm doing wrong with unpack here?
--
Matt Knecht <hex@voicenet.com>
------------------------------
Date: Wed, 06 Sep 2000 20:40:10 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: unpack and Solaris acct struct
Message-Id: <x7k8cpjlue.fsf@home.sysarch.com>
>>>>> "MK" == Matt Knecht <hex@voicenet.com> writes:
MK> # struct acct
MK> # {
MK> # char ac_flag;
MK> # char ac_stat;
MK> # uid_t ac_uid;
MK> # gid_t ac_gid;
MK> # dev_t ac_tty;
MK> # time_t ac_btime;
MK> # comp_t ac_utime;
MK> # comp_t ac_stime;
MK> # comp_t ac_etime;
MK> # comp_t ac_mem;
MK> # comp_t ac_io;
MK> # comp_t ac_rw;
MK> # char ac_comm[8];
MK> # };
MK> uid_t == long
MK> gid_t == long
MK> dev_t == unsigned long
MK> time_t == int
MK> comp_t == unsigned short
MK> my $unpack_fmt = "ccllLiSSSSSSA*";
MK> unpacking yields two extra bytes (Usually NULL, but not always)
MK> prepended to ac_comm. The acct structs are coming from Solaris 2.6,
MK> and I'm crunching the data on a Linux box. I've "duplicated" the acct
MK> struct in C on Linux, and I don't see these extra two bytes.
MK> Any thoughts about what I'm doing wrong with unpack here?
padding and porting.
you say prepended to ac_comm. maybe it is the 2 pad bytes after the
first 2 char fields. the uid field will be 4 byte aligned on sparc and
possibly/probably 2 byte aligned on 86. so put an xx after the initial
cc to skip the 2 pad bytes.
a good thing to do would be to write some c code to print the offsets of
each of the fields to make sure they start where you think they do. this
is easily done with a macro or by hand. something like this (very
untested but i have done this in the past):
struct acct *acct_base = NULL ;
offset = &acct_base->ac_uid ;
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Wed, 06 Sep 2000 20:59:35 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: Re: unpack and Solaris acct struct
Message-Id: <Xeyt5.2516$xL6.117230@news3.voicenet.com>
Uri Guttman <uri@sysarch.com> wrote:
>
>you say prepended to ac_comm. maybe it is the 2 pad bytes after the
>first 2 char fields. the uid field will be 4 byte aligned on sparc and
>possibly/probably 2 byte aligned on 86. so put an xx after the initial
>cc to skip the 2 pad bytes.
That was it. Thanks for the accurate debug.
--
Matt Knecht <hex@voicenet.com>
------------------------------
Date: 6 Sep 2000 07:14:00 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: use strict: why?
Message-Id: <8p4nb8$qs4$1@orpheus.gellyfish.com>
On Tue, 05 Sep 2000 08:07:51 GMT Tim Hammerquist wrote:
> I've noticed in this NG that 'use strict' is often encouraged much like
> a dealer pushes drugs. I completely understand it's benefits as a
> pragma. However, it's not a rule.
>
<snip>
You've hit right on the head when you say 'in this NG' - its just that you
havent realised. Partially its much like nearly everyone else has said
which amounts to 'look after the little things and the big things will take
care of themselves', but also its a realization that code posted here is
posted as an example and is likely to be cut pasted and used out of context
in all sorts of horrible ways by people who might not fully understand what
it does right now - firstly by making the code 'strict' and '-w' safe it
does at least stand some chance of surviving in any code environment it
might find itself in and secondly having it there means that when the code
becomes part of someones cargo cult then at least it begins to spread
good practice by stealth even if the people use it don't know that it is
good practice. I must admit that I typically make even the shortest snippet
of code strict safe if I am going to post it *here* (or indeed anywhere in
public).
Anyhow using 'strict' gives you something to type in those awkward first
moments of starting to write the program.
/J\
--
yapc::Europe in assocation with the Institute Of Contemporary Arts
<http://www.yapc.org/Europe/> <http://www.ica.org.uk>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 4241
**************************************
