[18979] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 1174 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 21 21:05:40 2001

Date: Thu, 21 Jun 2001 18:05:08 -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: <993171908-v10-i1174@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Thu, 21 Jun 2001     Volume: 10 Number: 1174

Today's topics:
        ANNOUNCE: new release of Time-modules 101.06_21_01 (David Muir Sharnoff)
    Re: CGI::CARP (carpout) or (fatalsToBrowser) ? <davsoming@lineone.net>
    Re: Click here to crash the browser? <davsoming@lineone.net>
        deleting a file: permission denied <barry@white.com>
        http://stein.cshl.org/WWW/software/CGI/#dos <davsoming@lineone.net>
    Re: http://stein.cshl.org/WWW/software/CGI/#dos <godzilla@stomp.stomp.tokyo>
        Is There Any Other Routine Like CHOP(); (Lars)
    Re: MAJOR perl bug (Sweth Chandramouli)
    Re: my $ref; vs. my $ref = {}; <ren@tivoli.com>
    Re: Parsing the arrow operator -> into English (Abigail)
    Re: Pattern matching with variables <Juha.Laiho@iki.fi>
    Re: Perl Tutorials or E-Books <phil.dobbin@btinternet.com>
    Re: Reference-problem <mischief@velma.motion.net>
    Re: Salary for teaching intro to perl <mischief@velma.motion.net>
    Re: simple reference question (Damian James)
    Re: Small Database Becomes Large Database <Juha.Laiho@iki.fi>
    Re: splice/Join and split!! <krahnj@acm.org>
    Re: Why does this split not work? <nospam@cfl.rr.com>
    Re: Why does this split not work? <ren@tivoli.com>
    Re: Why does this split not work? <ren@tivoli.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 21 Jun 2001 14:19:02 -0700
From: muir@idiom.com (David Muir Sharnoff)
Subject: ANNOUNCE: new release of Time-modules 101.06_21_01
Message-Id: <tj51qainjf3631@corp.supernews.com>

I've released a new version of Time-moduels (Time::ParseDate,
Time::JulianDay, etc).

This is mostly a bugfix releasse.  There are a couple of new
formats supported.

If you use PREFER_FUTURE please upgrade ASAP.

CHANGELOG:

	Paul Zimmer <pzimmer@bepress.com> found that '7/17/01' with
	PREFER_FUTURE failed badly.  Fixed.  This was also submitted
	by Dana Burd <DBurd@cpr.org>.

	Ben Daglish <bdaglish@yahoo.com> noted that array context
	was implying WHOLE and DATE_REQUIRED.  Fixed.

	Streppone Cosimo <cstrep@idgroup.it> requested support for
	postgresql's date format ("dd/mm/yyyy hh:mn:ss +tzo")

	Ameeth Linus Daniel <linus@teil.soft.net> found that IST wasn't 
	a defined timezone.  I've defined it as +0530, but I'm not 
	positive that's correct.

	Gautam Tripathi <dayalpura@hotmail.com> sent in a fix for
	timezone offset calculations making them consistent across
	all systems (no more problems with differing interpretations
	of negative modulus operations).

	Mike Nerone <mnerone@idworld.net> requested the syntax 
	"4 days ago".  He says that that syntax is suppored by
	GNU date.  This was also requested by Townsend, John E. 
	<John.Townsend@lexis-nexis.com>.

	Anton Berezin <tobez@heechee.tobez.org> notice that ParseDate
	couldn't handle "Sunday, 06-Nov-94 08:49:37 GMT" and sent
	in a patch.

You can get the new version from CPAN at:

http://www.cpan.org/authors/id/MUIR/modules/Time-modules-101.062101.tar.gz

or (until CPAN picks it up) at

ftp:://ftp.idiom.com/users/muir/CPAN/modules/Time-modules-101.062101.tar.gz

-Dave
-- 

--
Notice: Your mouse has been moved. Windows will now restart so this 
change can take effect.




------------------------------

Date: Fri, 22 Jun 2001 01:45:53 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Re: CGI::CARP (carpout) or (fatalsToBrowser) ?
Message-Id: <tj54u0kua63m5f@corp.supernews.co.uk>

qw(Thanks very much);
print @_,qw;
Guys :-);--

David Soming
'Just a head-banger- doing what I do best'





------------------------------

Date: Fri, 22 Jun 2001 02:03:07 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Re: Click here to crash the browser?
Message-Id: <tj55u9e3f9up8d@corp.supernews.co.uk>

>
> Please post the code you are really using. It's hard to say
> what your problem is if you don't show us the real thing.

I thought the problem was within my included post, as I said it works with
mailto but not with browsers. I have six files altogether and many subs so
its hard to narrow it down to just a few lines.
The program works- the only problem I have is with hypers?
If nothing obvious here then I'll assume its elswhere within my code as you
point out below.

>
> > In NN the hyperlink works but goes to:
> > http://www.mydomain.com/chat/$our_link
>
> The string "chat" does not even occur in the code above.
>
I know! this is strange as it's not part of the specified URL hmm...
Ill try and debug a little more-Thanks.
> cheers,
> stefan
>
--
David Soming
'Just a head-banger- doing what I do best'
______________




------------------------------

Date: Fri, 22 Jun 2001 08:20:16 +1000
From: Barry White <barry@white.com>
Subject: deleting a file: permission denied
Message-Id: <3B327320.573DD567@white.com>

I am running redhat v7.0.

I have written a small perl script, which creates 2 directories and two
html files, one in each directory, with directory permission set at 0777
during directoty creation.
I then go and have a look what was created, via a terminal window, all
looks good. But I am not able to delete the 2 files or directorys which
were created. Upon my attempt I get "unable to unlink file: permission
denied"
The owner is "apache". If i then log in as root, change permissions to
777, exit root, then i am able to delete files normally.

So questions are:
Why if the permissions are set at 777 during creation, why am i not able
to delete created files with a normal user login.
What do i need to do to be able to delete these files without having to
login as root.  

I intend to upload this cgi script to a remote host, so loggin in as
root to delete them is not possible.

I am hoping someone can give some advice.
BarryW


------------------------------

Date: Fri, 22 Jun 2001 01:09:05 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: http://stein.cshl.org/WWW/software/CGI/#dos
Message-Id: <tj52ovosmj4ufe@corp.supernews.co.uk>

Using CGI.pm
Is it actually possible to limit the size of posts in bytes to (any)
non-negative integer?
It seems no matter what the number specified here still allows posts of
around 100+ characters
I'm wanting to use this to limit posts to 30 characters for email addresses.
Would CGI::POST_MAX be the solution or is 100K the minimum?

http://stein.cshl.org/WWW/software/CGI/#dos
<QUOTE>$CGI::POST_MAX
If set to a non-negative integer, this variable puts a ceiling on the size
of POSTings, in bytes. If CGI.pm detects a POST that is greater than the
ceiling, it will immediately exit with an error message. This value will
affect both ordinary POSTs and multipart POSTs, meaning that it limits the
maximum size of file uploads as well. You should set this to a reasonably
high value, such as 1 megabyte.
$CGI::POST_MAX=1024 * 100;  # max 100K posts</QUOTE>

Thanks
--
David Soming
'Just a head-banger- doing what I do best'
______________




------------------------------

Date: Thu, 21 Jun 2001 17:30:17 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: http://stein.cshl.org/WWW/software/CGI/#dos
Message-Id: <3B329199.D2381274@stomp.stomp.tokyo>

David Soming wrote:

(snipped)

 
> Using CGI.pm

This is why you are experiencing problems.


> Is it actually possible to limit the size of posts in bytes to (any)
> non-negative integer?


Yes. Stop using CGI.poopmaker. Write your own fast
and efficient read and parse routine, then write your
own html form action incorporating appropriate maximum
length tags as needed.

Simple solution, yes?


Godzilla!


------------------------------

Date: Fri, 22 Jun 2001 00:23:30 GMT
From: Lars.Plessmann@gmx.de (Lars)
Subject: Is There Any Other Routine Like CHOP();
Message-Id: <3b328e67.11255051@news.btx.dtag.de>

I hava a list of items written to a file in windows.
when I open this file on unix systems, there seem to be 2 wrappings
(\n\n) at the end.
I use the chop routine which deletes one of them, that should be for
the line brake, but now there seem to be another char!? when I output
the chopped string I can see an space char (#32) at the end!

So now my question: is there any practical function to cut all special
characters (line brakes, spaces and so on) at the beginning and at the
end of my string?
Borland Delphi has such a routine, it's name is:
"function trim(s: string): string;"

is there a similar function in perl available?
if not, how can I realize that!? 2xchop is not the result, because
some strings do not have strange characters at the and, and in this
case importent chars would be cut!

thx in advance
Lars


------------------------------

Date: Thu, 21 Jun 2001 22:06:19 GMT
From: sweth+perl@gwu.edu (Sweth Chandramouli)
Subject: Re: MAJOR perl bug
Message-Id: <vduY6.100524$G5.21290162@news1.rdc1.md.home.com>

In article <slrn9it6j3.2hp.grey@teleute.dmiyu.org>,
Steve Lamb <morpheus@here.not.there> wrote:
>    As I said, it is this contextual behavior that is driving me away from
>perl since parens sometimes need to be used for grouping in logic yet they 
>can also alter the form of the data you're passing.
	Can you give some examples of this?  I can't think of a situation
where the parens would provide both "grouping" and change the list/scalar
context; you can't do things like

$ perl -e '@foo=qw(1 2 3);($bar or $baz) = @foo;'

	, for example.

	-- Sweth.

-- 
Sweth Chandramouli ; <sweth+perl@gwu.edu>



------------------------------

Date: 21 Jun 2001 15:47:09 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: my $ref; vs. my $ref = {};
Message-Id: <m3k825blwy.fsf@dhcp9-173.support.tivoli.com>

On Wed, 20 Jun 2001, pne-news-20010620@newton.digitalspace.net wrote:

> On Wed, 20 Jun 2001 09:23:22 -0700, "Arvin Portlock"
> <temp133@hotmail.com> wrote:
[snip]
> 
> Note that if you use an undefined value as if it were a hash
> reference, Perl automagically conjures up an anonymous hash and
> sticks a reference to it into the variable so that you can reference
> it. Thus, this:

[snip]

>> sub make_hash {
>>    my ($key, $value) = @_;
>>    my $hashref;
>>    $hashref->{$key}++ if $value;
>>    return $hashref;
>> }
> 
> This doesn't make a whole lot of sense to me. You return either
> undef or a reference to a hash with just one key.

This is just a practical example of the above.  As you've just
explained, an undefined value will autovivify as a hash reference when
it is used as a hash reference (well, in certain ways at least).

I think most would agree that this make_hash sub should really return
a hash reference, even if it's empty.  That certainly lends to the
argument that a hashref should be initialized as such.  It's not
necessary, but it is certainly more maintainable.

Of course, down that road lies Attribute::Types. :)

-- 
Ren Maddox
ren@tivoli.com


------------------------------

Date: 21 Jun 2001 22:05:58 GMT
From: abigail@foad.org (Abigail)
Subject: Re: Parsing the arrow operator -> into English
Message-Id: <slrn9j4s5s.hfs.abigail@alexandra.work.once.nl>

Uri Guttman (uri@sysarch.com) wrote on MMDCCCXXX September MCMXCIII in
<URL:news:x7snhmyygl.fsf@home.sysarch.com>:
** >>>>> "GW" == Guy Worthington <guyw@multiline.com.au> writes:
** 
**   GW> I don't think in Perl, e.g., the expression $$pointer{$i}, I 
**   GW> translate to "get the hash value at address $pointer{$i}", 
**   GW> where $$ I think of as the unary operator "get".  Given the 
**   GW> equivalent statement $pointer->{$i}, the best I can do is to 
**   GW> parse from right to left as "the value of the hash for key $i 
**   GW> access indirectly with pointer $pointer"; this is clumsy.  
** 
** $$ is not an operator in any way. the leading $ dereferences (as a
** scalar) the following scalar value. there is no get in that. also that
** expression is not proper. $ binds tighter than the hash index so that is
** really:
** 
** 	($$pointer){$i}
** 
** which is usually wrong.

Except that $$pointer {$i} *is* the same as $pointer -> {$i}, so I doubt
it is "usually wrong". Only if you have a hash %pointer where at key $i
you have stored a reference to a scalar, you want to use ${$pointer {$i}}.

As for pronouncing, '->' is silent; just like (most) $'s. So, $pointer -> {$i}
is pronounced "pointer i". Humans are remarkable good in filling in the
details. Sure, you might have a problem if you use %pointer and @pointer
to - but then, don't do that.



Abigail
-- 
sub _ {$_ = shift and y/b-yB-Y/a-yB-Y/                xor      !@ _?
       exit print                                                  :
            print and push @_ => shift and goto &{(caller (0)) [3]}}
            split // => "KsvQtbuf fbsodpmu\ni flsI "  xor       & _


------------------------------

Date: 21 Jun 2001 19:43:57 GMT
From: Juha Laiho <Juha.Laiho@iki.fi>
Subject: Re: Pattern matching with variables
Message-Id: <9gtipt$4g8$2@ichaos.ichaos-int>

si.cox@bbsrc.ac.uk (Loki) said:
>Now as . is a special char in pattern matching i have to proceed the .
>with a \
>
>If i have the line read: if (m/\.EXE/) {...... etc then the script
>works.
>However if the line reads: if (m/$pattern/) {...... with $pattern =
>"\.EXE" predeclared then it finds files like userexe.cfg as it is
>treating the . as a wildcard and ignoring the preceeding \.
 ...
>I know when perl does a pattern match it translates variables before
>doing the match but surely this means it should work declaring
>$pattern = "\.EXE".

 ... which would store just the text .EXE to the variable $pattern, as
\. within qouble quotes will be interpreted as ".". To avoid this (and
keep the backslash), use either an extra backslash or non-interpolating
quotes:
$pattern="\\.EXE";
$pattern='\.EXE';
-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ UH++++ UL++++$ P++@ L+++ E(-) W+$@ N++ !K w !O
         !M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h--- r+++ y+++
"...cancel my subscription to the resurrection!" (Jim Morrison)


------------------------------

Date: Thu, 21 Jun 2001 23:49:32 +0100
From: "Phil Dobbin" <phil.dobbin@btinternet.com>
Subject: Re: Perl Tutorials or E-Books
Message-Id: <9gttk8$3bd$1@neptunium.btinternet.com>

One last word on Perl books. A friend of mine bought "Perl For Dummies" 
(nobody had told him..). He's using MacPerl and splashed across the cover
was claims that the included CD-ROM had Perl acquisitions for Mac, indeed
inside were instructions for installing said on to a Mac. If you insert the
CD-ROM on a Mac, you get the ole "This disk is unreadable. Do you want to
intialise it?". (I e-mailed them on the subject and, to their credit,
offered to send a CD-ROM with Mac applicable software on it), but...
I'll stop on this thread now.
Have fun!
Phil.

--
"It was written that I should be
loyal to the nightmare
of my choice."
Heart of Darkness
Joseph Conrad

----------
In article <9gqpdr$lqr$1@news01.cit.cornell.edu>, "Young C. Fan"
<yf32@cornell.edu> wrote:


> "[coder]" <coder@binbash.net> wrote in message
> news:tiu6lup4vk40f6@corp.supernews.com...
>> Hey
>>
>> anyone know where i can find some perl tutorials or free e-books?
>
> I found this tutorial very helpful:
>
> http://www.comp.leeds.ac.uk/Perl/start.html
>
> 


------------------------------

Date: Thu, 21 Jun 2001 23:15:23 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Reference-problem
Message-Id: <tj500b52jsbt8b@corp.supernews.com>

Stefan Serena <sserena@freesurf.ch> wrote:
>> > Didn't know that. I thought it makes a copy to $_
>> > That means, the following code changes every entry of the array?
>>
>> > foreach $entry (@allentries) {
>> >     $entry = $entry x 2;    # can be anything...
>> > }
>>
>> Yep, and in fact many programs make good use of this behavior; it allows
>> you to step through an array and make changes to all or some of the
>> elements without having to manually index the array with a counter
>> variable.

> I see... I'm one of the programmers who always worked with a counter
> variable. But this changes for sure now! ;-)

In Perl, you only need a counter variable when you have to count
how many items there are. Isn't that great? It can be very liberating
to simply use a foreach loop.

BTW, when you quote someone, please show some sort of attribution
for that person.

Chris

-- 
You can never entirely stop being what you once were. That's
why it's important to be the right person today, and not put
it off till tomorrow. -- Larry Wall, 3rd State of the Onion



------------------------------

Date: Thu, 21 Jun 2001 23:27:57 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Salary for teaching intro to perl
Message-Id: <tj50ntk8749u87@corp.supernews.com>

Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "James" == James Richardson <time4tea@monmouth.com> writes:

> James> "Allan Peda" <tl082@yahoo.com> wrote in message
> James> news:20010620.103148.480298490.1213@yahoo.com...
>>> I am interested in teaching a basic perl class, say 20
>>> hours, which I expect will cover references and possibly
>>> some object oriented programming (just how to create an object).
> James> [...]
>>> What are reasonable salary numbers?

> James> Depends if you are teaching one of those shite classes with
> James> loads of flashy handouts, but no content, or a real course.

> And how many magazine columns you've written... I'm up to 133 at last

The books help, too. Don't forget your books, Randal. He has authored
or coauthored a number of them.

> count. :) Last I recall, Stonehenge is billing me out at $4000/day,
> although a *lot* of that is sucked down in overhead, and the lawyers
> and IRS seem to grab the rest. :)

That figure is also a bit higher because Randal knows much more than
Perl. He does security, HTML, XML, databases, etc. etc. etc.... and
he's notorious for his Perl skills, not 'Just another Perl Hacker'
as he claims. So, don't get discouraged if you make a little less
than Randal.

Also, remember that when Randal mentions lawyers, he has a lot to
talk about in that department. On his webpage,

    http://www.stonehenge.com/merlyn/

you can find out how to donate to his legal fund. You can search
for 'Intel Randal Schwartz' at Google and find over 1700 hits
describing the case.

I don't get billed out at $4000 a day, but I try to send a little
towards Randal's legal fund every so often. I'm not going to say
I've given a lot of money, but I'm sure every bit counts.

Chris

-- 
If they can get you asking the wrong questions, they don't
have to worry about the answers.
  -- Thomas Pynchon, Gravity's Rainbow



------------------------------

Date: 22 Jun 2001 00:08:16 GMT
From: damian@qimr.edu.au (Damian James)
Subject: Re: simple reference question
Message-Id: <slrn9j5326.1mv.damian@puma.qimr.edu.au>

Philip Newton chose Wed, 20 Jun 2001 16:13:04 +0200 to say this:
>On 20 Jun 2001 06:51:58 -0700, sierra@ecclectic.net (sierra) wrote:
>
>> use $input;
>
>'use' works at compile time, while $input isn't filled until runtime.
>
>Also, use requires a bareword. You might be able to use something like
>
>    require "$input.pm";
>    import $input;
>
>to simulate the 'use', but this will not make available constants or
>change prototypes.
>

There is also a potential security problem if the user is not trusted --
you might want to consider running with taint mode on, then untainting
$input.

Another way around this, and also a way to check for erroneous input, is
to use a lookup hash with the module names as values:

[ example code -- untested ]
my %_lookup = (
	mod1	=>	'Module1.pm',
	mod2	=>	'Module2.pm'
);
my $input;

INPUT: while (1) {
	chomp( $input = <STDIN> );
	last INPUT if exists $_lookup{lc $input};
	print "Bad value: $input. Try again.\n";
}
require "$_lookup{lc $input}";

__END__

That way you have complete control over the actual modules require()ed.
Including a check for the presence of the module in @INC is also possible.

HTH,
Cheers,
Damian


------------------------------

Date: 21 Jun 2001 19:37:30 GMT
From: Juha Laiho <Juha.Laiho@iki.fi>
Subject: Re: Small Database Becomes Large Database
Message-Id: <9gtidq$4g8$1@ichaos.ichaos-int>

Paul Dempsey <dempsey@dickinson.edu> said:
>I have a simple Unix DBM file of about 200 records, each record about
>300 bytes. I needed to change the keys for this file, so I read the file
>in and wrote to a different DBM file with the new key.
>
>The problem is my new data file has grown from 250 KB to to 25 MB in
>size. I can't figure this out. I even wrote the old data to a text file
>and created the new DBM file from that text data, but I still got a 25
>MB file.

Hmm.. size or allocation? If size, then there's nothing to worry about;
the dbm library just created a sparse file for some reason.

Check with (ok, this isn't a dbm file, but just something I created):
$ ls -ls /tmp/foo
   4 -rw-rw-r--    1 jlaiho   jlaiho    1048577 Jun 21 22:32 /tmp/foo
The "4" is allocation in blocks (typically of 512 bytes), so this file
has "size" of 1048577 bytes, but disk space allocation of 2kbytes.
This is because the file actually contains just one character or true
data, but at an offset 1024k (I created that with
"dd if=/dev/zero of=/tmp/foo seek=1024k bs=1 count=1").

It is very much possible that what you're seeing is a sparse file; they're
not that uncommon with dbm implementations.
-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ UH++++ UL++++$ P++@ L+++ E(-) W+$@ N++ !K w !O
         !M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h--- r+++ y+++
"...cancel my subscription to the resurrection!" (Jim Morrison)


------------------------------

Date: Thu, 21 Jun 2001 22:59:29 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: splice/Join and split!!
Message-Id: <3B327C4E.E00B8AD@acm.org>

Michael Carman wrote:
> 
> John Plaxton wrote:
> >
> > I am reading a text file into an array.I am then changing some
> > of the rows before writing back to text file.
> 
> An operation that should almost certainly be done line-by-line:
> slurping entire files doesn't scale well when the files get big.
> 
> > This is the bit of code that should alter the array:
> >
> >   for($x=6;$x<10;$x++){
> >     my $oldrow = $filedata[$x];
> >     my ($autold,$dold,$avold,$yold,$pold,$paold) =
> >             split(/\|/, $oldrow);
> >     my $newrow = join '|',$aut,$dold,$avail,$yold,$p,$pa;
> >     splice(@filedata,$x,1,$newrow);
> > } # end for loop
> 
> As an example of more idiomatic Perl, I'd do it this way:
> [Expanding your context a little]
> 
> while (<IN>) {
>     if ($. == 6 .. $. == 9) {
          ^^^^^      ^^^^^^
The "$. ==" part is superfluous.

    if ( 6 .. 9 ) {


>         my (undef, $dold, undef, $yold) = split(/\|/, $_);
>         $_  = join('|', $aut, $dold, $avail, $yold, $p, $pa);
>         $_ .= "\n";
>     }
>     print;
> }



John
-- 
use Perl;
program
fulfillment


------------------------------

Date: Thu, 21 Jun 2001 22:05:05 GMT
From: tuxy <nospam@cfl.rr.com>
Subject: Re: Why does this split not work?
Message-Id: <3B32705C.6C2D98F6@cfl.rr.com>

OK, here is the story.  I fed a buffer to a split and got an error
message for which there is no possible explaination other than Perl 5.6
split is (sometimes) broken. It said I had an undefined value on line 10
(among other lines at different times) of file <IN>. I have not defined
<IN> in my script, so it much be something split uses. 

Therefore:

 1.  The buffer itself must have been defined when the split was called,
otherwise how could it get to line 10?

 2. There are no characters I can introduce into a buffer of which I'm
aware that would cause the buffer to become undef except perhaps a lack
of an end character. Since I created the buffer with a join I'd hope
that it has all of its constituients correctly defined.

 3. The 5.6 split pukes at various lines in the file at different times,
saying that line this or that is undefined. There are no special
characters in the file, and every line has at lease some text on it.
Diagnostics offer no insight.

 4. I moved the same code and data to a 5.004 box and it works fine, no
warnings or errors.

 3. I too can get simple cases working. Of course. But in this
particular large (>1000 line) proprietary buffer, it dies. 

 4. Not being someone who puts special demands on the compiler like say
Damian or other gurus, I presumed (apparently incorrectly) that someone
would have chimed in with (oh yeah P5.6 can't handle large buffers) or
something like that. This isn't like some exotic testcase. I also spent
a lot of time in perdoc looking for limitations on split and found none
stated.

Now if you want to presume that I made up the error message and this
didn't happen fine. As far as I'm concerned, 5.6 split is screwed up.
Maybe its just OUR installation of 5.6. Who knows? All I know is I coded
a legitimate solution in what is generally a pretty stable language for
me, and it choked. No big drama - I go back to 5.004. Or code it another
way. 

The community would be better served if you put as much energy into
understanding and helping to correct problems in lieu of attacking those
who present them.

 

 



Bart Lateur wrote:
> 
> tuxy wrote:
> 
> >Get over your wonderful self and look at the facts. The damn thing
> >doesn't work; I coded a legitimate solution and Perl choked. So kill me
> >that I'm not tickled to death with that.
> 
> The damn thing works on my 5.6.0. So are you sure it chokes on THIS
> particular line? Print out $buf just above this line, perhaps using
> Data::Dumper. See if indeed $buf is not undef. That is what I would
> think.
> 
> --
>         Bart.


------------------------------

Date: 21 Jun 2001 16:33:35 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: Why does this split not work?
Message-Id: <m3g0ctbjrk.fsf@dhcp9-173.support.tivoli.com>

On Thu, 21 Jun 2001, nospam@cfl.rr.com wrote:

> As far as what I present, it would not be responsible on my part to
> post a >1000 line proprietary file to a newsgroup for more than 1
> reason. I described what Perl did, and how it was broken. I presume
> that much less thourough testing would reveal similar flaws.

Perhaps it isn't obvious, but we have not been able to reveal any such
flaws, even with very thorough testing.  Perhaps you could reproduce
the problem in a smaller context and post that here?  If it is a bug
with Perl 5.6.1, then we need to get some more detail so that we can
get it fixed.

-- 
Ren Maddox
ren@tivoli.com


------------------------------

Date: 21 Jun 2001 17:20:46 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: Why does this split not work?
Message-Id: <m3ae31bhkx.fsf@dhcp9-173.support.tivoli.com>

On Thu, 21 Jun 2001, nospam@cfl.rr.com wrote:

> OK, here is the story.  I fed a buffer to a split and got an error
> message for which there is no possible explaination other than Perl
> 5.6 split is (sometimes) broken. It said I had an undefined value on
> line 10 (among other lines at different times) of file <IN>. I have
> not defined <IN> in my script, so it much be something split uses.

When Perl prints a warning, it also indicates what line number any
open filehandles are on.  It may have absolutely nothing to do with
the warning itself.  It is just extra information.  It has nothing at
all to do with split.

> Therefore:
> 
>  1.  The buffer itself must have been defined when the split was
>  called, otherwise how could it get to line 10?

The line 10 reference is not related to split.

>  2. There are no characters I can introduce into a buffer of which
>  I'm aware that would cause the buffer to become undef except
>  perhaps a lack of an end character. Since I created the buffer with
>  a join I'd hope that it has all of its constituients correctly
>  defined.

You haven't shown us how you're building/processing $buf, so it is
difficult to comment on this.

>  3. The 5.6 split pukes at various lines in the file at different
>  times, saying that line this or that is undefined. There are no
>  special characters in the file, and every line has at lease some
>  text on it.  Diagnostics offer no insight.

The best thing to do would be to print the value of $buf immediately
before the call to split.  That way you can really see what's going
on.

>  4. I moved the same code and data to a 5.004 box and it works fine,
>  no warnings or errors.

Glad that you found a work-around.  Obviously *something* is different
between 5.004 and 5.6.1, and it may in fact be a bug.  But we're going
to need more information to narrow down the problem.

>  3. I too can get simple cases working. Of course. But in this
>  particular large (>1000 line) proprietary buffer, it dies.

Yeah, got to hate it when that happens.  Complexity increases
exponentially, so it could be something very subtle.

>  4. Not being someone who puts special demands on the compiler like
>  say Damian or other gurus, I presumed (apparently incorrectly) that
>  someone would have chimed in with (oh yeah P5.6 can't handle large
>  buffers) or something like that. This isn't like some exotic
>  testcase. I also spent a lot of time in perdoc looking for
>  limitations on split and found none stated.

That seems like a reasonable expectation, but AFAIK no one has found
anything like that.

[rest snipped]

-- 
Ren Maddox
ren@tivoli.com


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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.  

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 V10 Issue 1174
***************************************


home help back first fref pref prev next nref lref last post