[28752] in Perl-Users-Digest
Perl-Users Digest, Issue: 10116 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 4 14:05:56 2007
Date: Thu, 4 Jan 2007 11:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 4 Jan 2007 Volume: 10 Number: 10116
Today's topics:
A difficulty with *surprising autovivification* in usi <imfeaw5672@pacbell.net>
Re: A difficulty with *surprising autovivification* in <DJStunks@gmail.com>
DBI problem -- storing large value into an INT8 field mailbox@cpacker.org
Re: DBI problem -- storing large value into an INT8 fie <DJStunks@gmail.com>
Re: DBI problem -- storing large value into an INT8 fie <DJStunks@gmail.com>
Re: DBI problem -- storing large value into an INT8 fie mailbox@cpacker.org
Re: How can I access variables in my perl script from a <zen13097@zen.co.uk>
incorrect behaviour in use clause specifying Class::Std <julien.ollivier@gmail.com>
Re: incorrect behaviour in use clause specifying Class: <mritty@gmail.com>
Iterate through words in a string <gcastro@mathworks.com>
Net::SSH::Perl question <kanuri.sai-kiran@in.standardchartered.com>
Re: Net::SSH::Perl question usenet@DavidFilmer.com
Re: Problems with use locale and regexp anno4000@radom.zrz.tu-berlin.de
Re: Silly li'l perl script, plx improve. <emschwar@pobox.com>
Re: Silly li'l perl script, plx improve. <klaus03@gmail.com>
Re: Unsecured scripts and site hacking? <brian.d.foy@gmail.com>
Re: Unsecured scripts and site hacking? <scobloke2@infotop.co.uk>
Re: Unsecured scripts and site hacking? <wahab-mail@gmx.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 04 Jan 2007 18:40:02 GMT
From: "sm" <imfeaw5672@pacbell.net>
Subject: A difficulty with *surprising autovivification* in using %HASH
Message-Id: <6Sbnh.13565$yC5.6156@newssvr27.news.prodigy.net>
Hi,
I am having a lot of difficulty with testing to see if a hash entry is
defined/exists/etc.
I know of the problem of *surprising autovivification* in hash (
http://perldoc.perl.org/functions/exists.html)
but have not been able to find a solution that I can use (Although the
deepest nested array or hash
will not spring into existence just because its existence was tested, any
intervening ones will.)
I was womdering if anyone could help or provide a hind for a satisfactory
workaround.
#### http://perldoc.perl.org/functions/exists.html
#
# exists EXPR
#
# Given an expression that specifies a hash element or array element,
# returns true if the specified element in the hash or array has ever
# been initialized, even if the corresponding value is undefined. The
# element is not autovivified if it doesn't exist.
#
# print "Exists\n" if exists $hash{$key};
# print "Defined\n" if defined $hash{$key};
# print "True\n" if $hash{$key};
#
#
# print "Exists\n" if exists $array[$index];
# print "Defined\n" if defined $array[$index];
# print "True\n" if $array[$index];
#
# A hash or array element can be true only if it's defined, and defined
# if it exists, but the reverse doesn't necessarily hold true.
#
#
# if (exists $ref->{A}->{B}->{$key}) { }
# if (exists $hash{A}{B}{$key}) { }
#
#
# if (exists $ref->{A}->{B}->[$ix]) { }
# if (exists $hash{A}{B}[$ix]) { }
# if (exists &{$ref->{A}{B}{$key}}) { }
#
# Although the deepest nested array or hash will not spring into existence
# just because its existence was tested, any intervening ones will. Thus
# $ref->{"A"} and $ref->{"A"}->{"B"} will spring into existence due to
# the existence test for the $key element above. This happens anywhere
# the arrow operator is used, including even:
#
# undef $ref;
# if (exists $ref->{"Some key"}) { }
# print $ref; # prints HASH(0x80d3d5c)
#
# This surprising autovivification in what does not at first--or
# even second--glance appear to be an lvalue context may be fixed
# in a future release.
#
########################################################################
##
## This is true for *exists*, *defined* and a simple referencing
## of a hash that any of these will cause the
## *surprising autovivification*
print "\n\n", '#'x8, ' HASH behavior ', '#'x20, "\n";
print "\nchecking *exists* ", '='x50, "\n";
print "Exists\n" if exists $hash{xxx}{kkk};
print "xxx Exists\n" if exists $hash{xxx};
print "xxx,kkk Exists\n" if exists $hash{xxx}{kkk};
print "\nchecking *defined* ", '='x50, "\n";
print "Defined\n" if defined $hash{zzz}{uuu};
print "zzz Defined\n" if defined $hash{zzz};
print "zzz,uuu Defined\n" if defined $hash{zzz}{uuu};
print "\nchecking *simple referencing* ", '='x50, "\n";
print "True\n" if $hash{ppp}{qqq};
print "ppp True\n" if $hash{ppp};
print "ppp,qqq True\n" if $hash{ppp}{qqq};
print "\nchecking *values* ", '='x50, "\n";
print "True\n" if values %{$hash{aaa}{bbb}};
print "aaa True\n" if $hash{aaa};
print "aaa,bbb True\n" if $hash{aaa}{bbb};
print "\nchecking *keys* ", '='x50, "\n";
print "True\n" if keys %{$hash{aaa}{bbb}};
print "aaa True\n" if $hash{aaa};
print "aaa,bbb True\n" if $hash{aaa}{bbb};
#end
Regards,
-sm
------------------------------
Date: 4 Jan 2007 11:02:45 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: A difficulty with *surprising autovivification* in using %HASH
Message-Id: <1167937365.125034.188510@11g2000cwr.googlegroups.com>
sm wrote:
> Hi,
>
> I am having a lot of difficulty with testing to see if a hash entry is
> defined/exists/etc.
> I know of the problem of *surprising autovivification* in hash (
> http://perldoc.perl.org/functions/exists.html)
> but have not been able to find a solution that I can use (Although the
> deepest nested array or hash
> will not spring into existence just because its existence was tested, any
> intervening ones will.)
A common question. Uri has written an excellent article on autoviv --
pay particular attention to the deep_exists subroutine.
http://www.perlarchive.com/articles/perl/ug0002.shtml
-jp
------------------------------
Date: 4 Jan 2007 07:28:18 -0800
From: mailbox@cpacker.org
Subject: DBI problem -- storing large value into an INT8 field
Message-Id: <1167924498.082608.68420@s80g2000cwa.googlegroups.com>
I'm having trouble using the DBI module
with an INFORMIX database. I have a table
with a column variable called "filesize" defined
as INT8. Given a value greater than 2**31,
say 4154628096, that I want to store into it,
if I code
$S = $dbk->prepare("UPDATE stat_daily SET filesize = 4154628096")
$S->execute();
...this will store the correct value. But if I code
$Size = 4154628096;
$S = $dbk->prepare("UPDATE stat_daily SET filesize = ?");
$S->execute($Size);
...it stores a meaningless value. Our version of Perl is not
64-bit enabled and upgrading is not an option. We get away
with doing precise integer arithmetic with large values
within our scripts presumably because Perl's native floating
point uses a large number of fraction bits. But that fact
doesn't help me here. Is there a workaround? (If there's
anything in perldoc DBI on this, I've missed it...)
--
Charles Packer
mailboxATcpacker.org
------------------------------
Date: 4 Jan 2007 10:20:56 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: DBI problem -- storing large value into an INT8 field
Message-Id: <1167934855.940379.218070@i15g2000cwa.googlegroups.com>
mailbox@cpacker.org wrote:
> I'm having trouble using the DBI module
> with an INFORMIX database. I have a table
> with a column variable called "filesize" defined
> as INT8. Given a value greater than 2**31,
> say 4154628096, that I want to store into it,
> if I code
>
> $S = $dbk->prepare("UPDATE stat_daily SET filesize = 4154628096")
> $S->execute();
>
> ...this will store the correct value.
because this passes the information as a simple string to the database
for interpretation.
> But if I code
> $Size = 4154628096;
> $S = $dbk->prepare("UPDATE stat_daily SET filesize = ?");
> $S->execute($Size);
>
> ...it stores a meaningless value. Our version of Perl is not
> 64-bit enabled and upgrading is not an option.
I assume the issue is that Perl (without 64bitint support) cannot
assign the value 4154628096 to a scalar (try printing $Size after the
assignment...) therefore my suggestion is to set $Size to the
stringified version:
$Size = '4154628096';
you may then need to cast the filesize in your UPDATE as an integer
from a string (or not, depending on how forgiving Informix is). As the
DBI docs indicate you can do this on the database side, or you can do
it on the Perl side as follows:
use DBI qw{ :sql_types };
my $sql = 'UPDATE stat_daily SET filesize = ?';
my $size = '4154628096';
$sth->prepare( $sql );
$sth->bind_param(1, $size, SQL_INTEGER);
$sth->execute();
Your setup is unique enough that I can't test any of this, so try it
out.
HTH,
-jp
------------------------------
Date: 4 Jan 2007 10:35:08 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: DBI problem -- storing large value into an INT8 field
Message-Id: <1167935705.696001.62930@42g2000cwt.googlegroups.com>
DJ Stunks wrote:
> $sth->prepare( $sql );
by which I meant
my $sth = $dbh->prepare( $sql );
of course :-)~
-jp
------------------------------
Date: 4 Jan 2007 11:03:43 -0800
From: mailbox@cpacker.org
Subject: Re: DBI problem -- storing large value into an INT8 field
Message-Id: <1167937423.810612.194540@6g2000cwy.googlegroups.com>
DJ Stunks wrote:
> mailbox@cpacker.org wrote:
> assignment...) therefore my suggestion is to set $Size to the
> stringified version:
>
> $Size = '4154628096';
>
> you may then need to cast the filesize in your UPDATE as an integer
> from a string (or not, depending on how forgiving Informix is). As the
> DBI docs indicate you can do this on the database side, or you can do
That's it! All I had to do, in fact was stringify $Size:
$StrSize = sprintf("%s", $Size);
...and DBI took it in the original format of my execute statement
without
any kind of casting:
$I->execute($StrSize);
Earlier, though, I had tried
$S = $dbk->prepare("UPDATE stat_daily SET size = '4154628096' ");
...and got an error message, and this failure diverted me away from
the stringifying solution. Thanks very much.
--
Charles Packer
mailboxATcpacker.org
------------------------------
Date: 04 Jan 2007 09:33:48 GMT
From: Dave Weaver <zen13097@zen.co.uk>
Subject: Re: How can I access variables in my perl script from a sub in a module
Message-Id: <459cc9fc$0$32022$fa0fcedb@news.zen.co.uk>
On Wed, 3 Jan 2007 15:50:11 -0800, sm <imfeaw5672@pacbell.net> wrote:
> Hi Folks,
>
> How can I access some of the variables in my perl script from a perl module.
> example
>
> #!/usr/bin/perl
use strict;
use warnings;
> use this_pakage;
>
> my $VARA = 72;
> my $VARB = 44;
^^
our $VARA;
our $VARB;
Lexical variables (declared using 'my') are not accessible outside
their lexical scope. Using 'our' will declare a package variable
instead, which *can* be accessed from elsewhere.
However, using 'global' variables is a poor approach to sharing data
betwwen modules.
> this::pakage::get_vara_value();
^^ ^
this_package::get_vara_value();
A pooly named sub, since it is not actually "get"ting anything, merely
printing something.
> sub get_vara_value {
> my $AAA = $main::$VARA; ## how do I access $VARA in my script
^
my $AAA = $main::VARA
Using caps is not the best convention for sub-scoped lexical
variables.
> print $AAA \n";
> }
1;
Your module should end with a true value.
Also, on the whole, modules shouldn't really be accessing things from
main - it's usually the other way around.
Here's an example of a better way (UNTESTED):
#!/usr/bin/perl
use strict;
use warnings;
use Foo;
my $wotsit = Foo::get_wotsit();
print "Wotsit = $wotsit\n";
----- Foo.pm:
package Foo;
use strict;
use warnings;
{ # this block restricts the scope of $Wotsit,
# so other subs in package Foo can't access it.
# You should always restrict the scope of a viariable
# to the smallest it needs to be.
my $Wotsit = 123;
sub get_wotsit {
return $Wotsit;
}
}
# other subs here
1;
------------------------------
Date: 4 Jan 2007 09:21:03 -0800
From: "Julien" <julien.ollivier@gmail.com>
Subject: incorrect behaviour in use clause specifying Class::Std version in perl 5.8.8
Message-Id: <1167931263.657180.49090@51g2000cwl.googlegroups.com>
Hi,
After discovering that I was accidentally using Class::Std version
0.0.2 instead of 0.0.8, I tried to specify the version in the use
clause to detect such problems in the future. However, perl 5.8.8
doesn't seem to handle this properly. Since I have already installed
Class::Std version 0.0.8, I will try to require version 0.0.9 to
illustrate the problem I had (even though 0.0.9 doesn't yet exist):
Under perl 5.8.6, the use clause works:
[user@host ~]$ perl --version
This is perl, v5.8.6 built for i386-linux-thread-multi
Copyright 1987-2004, Larry Wall
Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source
kit.
Complete documentation for Perl, including FAQ lists, should be found
on
this system using `man perl' or `perldoc perl'. If you have access to
the
Internet, point your browser at http://www.perl.org/, the Perl Home
Page.
[user@host ~]$ perl -e 'use Class::Std 0.000009;'
Class::Std version 0.000009 (v0.0.9) required--this is only version
0.000008 (v0.0.8) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
... so compilation failed, which is what I wanted/expected. However
under perl 5.8.8 :
[user@host ~]$ perl --version
This is perl, v5.8.8 built for i386-linux-thread-multi
Copyright 1987-2006, Larry Wall
Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source
kit.
Complete documentation for Perl, including FAQ lists, should be found
on
this system using "man perl" or "perldoc perl". If you have access to
the
Internet, point your browser at http://www.perl.org/, the Perl Home
Page.
[user@host ~]$ perl -e 'use Class::Std 0.000009;'
[user@host ~]$ perl -e 'use Class::Std 1.000009;'
Class::Std version 1.000009 (v1.0.9) required--this is only version
0.000008 (v0.0.8) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
So we see that the installed Class::Std is version 0.0.8, but requiring
version 0.0.9 doesn't work (i.e. compilation did not fail). Requiring
v1.0.9 does lead to a compilation failure however.
Am I doing something wrong? It seems that leading 0's aren't being
handled properly under perl 5.8.8? Should I report this as a bug?
Thanks,
Julien
------------------------------
Date: 4 Jan 2007 10:11:48 -0800
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: incorrect behaviour in use clause specifying Class::Std version in perl 5.8.8
Message-Id: <1167934308.193354.5890@6g2000cwy.googlegroups.com>
Julien wrote:
> I tried to specify the version in the use
> clause to detect such problems in the future. However, perl 5.8.8
> doesn't seem to handle this properly.
> [user@host ~]$ perl -e 'use Class::Std 0.000009;'
> [user@host ~]$ perl -e 'use Class::Std 1.000009;'
> Class::Std version 1.000009 (v1.0.9) required--this is only version
> 0.000008 (v0.0.8) at -e line 1.
> BEGIN failed--compilation aborted at -e line 1.
>
> So we see that the installed Class::Std is version 0.0.8, but requiring
> version 0.0.9 doesn't work (i.e. compilation did not fail). Requiring
> v1.0.9 does lead to a compilation failure however.
>
> Am I doing something wrong? It seems that leading 0's aren't being
> handled properly under perl 5.8.8? Should I report this as a bug?
I can't duplicate your results with my perl, v5.8.4 solaris:
$ perl -MClass::Std -le'print $Class::Std::VERSION'
v0.0.8
$ perl -e'use Class::Std 0.000008'
$ perl -e'use Class::Std 0.000009'
Class::Std version 0.000009 (v0.0.9) required--this is only version
0.000008 (v0.0.8) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
$ perl -e'use Class::Std 1.000000'
Class::Std version 1.000 (v1.0.0) required--this is only version
0.000008 (v0.0.8) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
$ perl -v
This is perl, v5.8.4 built for sun4-solaris
Paul Lalli
------------------------------
Date: Thu, 04 Jan 2007 13:57:58 -0500
From: Gonzalo Castro <gcastro@mathworks.com>
Subject: Iterate through words in a string
Message-Id: <C1C2B866.492D%gcastro@mathworks.com>
I'm have a string I am constructing with space delimited words. I would like
to iterate through each word later. I thought making an array from the
contents of the string would be the convenient way to approach this but I'm
not having any luck. Any ideas?
I construct a string in code similar to this:
$accumulator = ""
while (some condition)
{
$anotherString = getMeAnotherString();
$accumulator = $accumulator . " $anotherString"
}
Then I try to make an array but this is clearly not right. What's the right
way to do this?
@array = qw($accumulator);
When I iterate
for $element (@array)
{
print "element = $element";
}
I get this:
element = $accumulator
You might ask, "Why not simply add/push $anotherString onto an array first
instead of concatenating into a string?" And I would answer, "Well, because
I want the list of words to be the value part of a key/value hash and values
have to be scalar. Am I right?"
Thanks,
Gonzalo
------------------------------
Date: 4 Jan 2007 04:57:48 -0800
From: "Sai Kiran" <kanuri.sai-kiran@in.standardchartered.com>
Subject: Net::SSH::Perl question
Message-Id: <1167915468.658422.288310@42g2000cwt.googlegroups.com>
Hi,
I have a requirement where i need to login to a remote server and then
su to another user for executing commands. The problem that i am facing
is that i am not able to find how to pass the password for the su
command after i login into the remote system.
My code looks like this?
#!/usr/bin/perl
use strict;
use warnings;
use Net::SSH::Perl;
my ($host,$user,$pass);
( $host, $user, $pass ) = ('hostname', 'username', 'passwd' );
my $conn = Net::SSH::Perl->new($host,"protocol 2,1");
$conn->login($user,$pass);
my ( $out,$err,$exit) = $conn->cmd('su - username "ls -l"
','password');
print " -------- $host -----------\n";
if ( $exit == 0 )
{ print $out."\n"; }
else
{ print $err."\n"; }
any pointers on where i going wrong?
I know that password cannot be passed as stdin to su. Any other ideas
or suggestion are highly welcome.
Thanking you.
------------------------------
Date: 4 Jan 2007 09:53:12 -0800
From: usenet@DavidFilmer.com
Subject: Re: Net::SSH::Perl question
Message-Id: <1167933192.727634.26910@s80g2000cwa.googlegroups.com>
Sai Kiran wrote:
> is that i am not able to find how to pass the password for the su
> command after i login into the remote system.
The only way I know of to do that is by the use of Expect:
http://search.cpan.org/~rgiersig/Expect-1.20/Expect.pod
--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)
------------------------------
Date: 4 Jan 2007 08:11:34 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Problems with use locale and regexp
Message-Id: <503r5mF1egqo2U1@mid.dfncis.de>
<felix.ostmann@thewar.de> wrote in comp.lang.perl.misc:
> is there any good solution at this time?
Solution to what? Please don't top-post.
> $content =~ s!^\[\[[a-z]{2}:.*.\]$!!gm; ## "\]\]" => ".\]"
>
> Thanks for your help, what is the correct handling when i found
> something like this? where is the perl-bug-tracking (or so). I never
> use such a system bevor :(
[tofu snipped]
perldoc perlbug
Anno
------------------------------
Date: 03 Jan 2007 22:54:51 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Silly li'l perl script, plx improve.
Message-Id: <87odpfcp5g.fsf@aragorn.emschwar>
George Orwell <nobody@mixmaster.it> writes:
> #!/usr/bin/perl
> # Public Domain
> use strict;
> use warnings;
Good so far.
> open(IN, "$ARGV[0]") or die("No input file. Use perldoc $0 for more
> info.\n");
You needlessly quote $ARGV[0] there; I'm not sure why. This can be
improved with lexical filehandles and the three-arg form of open(),
but major kudos for handling the failure with die. However, there are
more reasons for failing to open than the file not existing-- you may
not have read permissions, for instance. Just let Perl tell you why
it didn't work:
open my $infile, '<', $ARGV[0] or die "Couldn't open $ARGV[0]: $!";
> my @in = <IN>;
You're only processing it line-by-line below, so why bother reading it
in all at once? If the file is large, this could use a lot more
memory than you are expecting. Omit this line entirely.
> if($ARGV[1]){
> open(OUT, ">>", "$ARGV[1]");
> select OUT;
> }
See above-- you need to check for failure to open the output file as
well, because you might not have permissions to write in that
directory, or the file could already exist, and you don't have
permissions to write to it, or any number of other things.
if($ARGV[1]){
open my $outfile, ">>", $ARGV[1])
or die "Couldn't open $ARGV[1] for output: $!";
select $outfile;
}
Note: because $outfile is declared in the if block, you can't refer to
it later. If you want to modify the program to use it later, you'll
need to declare $outfile outside the loop:
my $outfile;
if ($ARGV[1]) {....}
> # The regex below does all the work... (I'm sure you could write this
> program in a one-liner...)
> foreach(@in){
> if($_=~m/(http:\/\/\S+\.[\w\d.\/_%]+)/){
> print "$1\n";
> }
> }
> close(IN);
It's hard to tell what you want from your regex, as you are not
matching URLs with port numbers in them, or with GET parameters
(following a '?' character). I'll fix it in a VERY ugly way below.
Use HTML::LinkExtor instead.
# this reads one line at a time from $infile, which means you don't have
# to have the whole thing in memory at once.
# also, the regex is untested, and probably misses a few special cases--
# kinda rushed through rfc1808
while(<$infile>) {
print $1 if m|(http:// # protocol
[-\w.]+ # host
(?: :\d+)? # port number (optional)
/[\`-%$.+!*'(),\w:@&=]* # path
(?: \?[\`-%$.+!*'(),\w;/?:@&=]) # query
)
|igsmx;
}
Ugh! That's ugly (and probably broken, because I can't be arsed to
test it.)
Here's something pretty:
#!/usr/bin/perl
use warnings;
use strict;
use HTML::LinkExtor;
my $extractor = HTML::LinkExtor->new();
$extractor->parse_file($ARGV[0]);
if($ARGV[1]){
open my $outfile, ">>", $ARGV[1])
or die "Couldn't open $ARGV[1] for output: $!";
select $outfile;
}
print "Links found in $ARGV[0]:\n"
foreach ($extractor->links()) {
my ($tag, %links) = @{$_};
print join("\n", grep /^http:/ values %links);
}
NOTE: also untested, but I'm a heck of a lot more confident in that
one than I am in the previous one.
-=Eric
------------------------------
Date: 4 Jan 2007 02:51:19 -0800
From: "Klaus" <klaus03@gmail.com>
Subject: Re: Silly li'l perl script, plx improve.
Message-Id: <1167907878.962161.252310@6g2000cwy.googlegroups.com>
Eric Schwartz wrote:
> if($ARGV[1]){
> open my $outfile, ">>", $ARGV[1])
> or die "Couldn't open $ARGV[1] for output: $!";
> select $outfile;
> }
>
> Note: because $outfile is declared in the if block, you can't refer to
> it later. If you want to modify the program to use it later, you'll
> need to declare $outfile outside the loop:
I agree, and I would like to add what I think will happen in the above
code fragment under the condition that $ARGV[1] is defined and not ""
and not "0" and not 0:
- the condition if($ARGV[1]) is true, so we enter the if-branch
- the file $ARGV[1] is opened as $outfile for output (append)
- and, given that the open was successful,
- sets the default to $outfile for all subsequent prints (select)
- the file $outfile is closed as the scope of the if exits
Now, for the rest of the program, all subsequent prints fail silently
because print now defaults to the closed filehandle $outfile.
I did not test the above scenario, but would like to ask anyway:
Am I right ?
> my $outfile;
> if ($ARGV[1]) {....}
------------------------------
Date: Thu, 04 Jan 2007 03:14:36 -0600
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: Unsecured scripts and site hacking?
Message-Id: <040120070314360595%brian.d.foy@gmail.com>
In article <NqadnbCQLPM1jwHYRVnyhgA@bt.com>, Alison
<invalid@NOSPAM.com> wrote:
> Charlton Wilbur <cwilbur@chromatico.net> wrote in message
> news:87lkkjyiew.fsf@mithril.chromatico.net...
> > >>>>> "A" == Alison <invalid@NOSPAM.com> writes:
> >
> > --
> > Charlton Wilbur
> > cwilbur@chromatico.net
>
> Hi Charlton,
>
> Thanks for your reply. As far as root access goes, full access is only
> available locally to the server.
The only secure computer is the one that's turned off, unplugged,
encased in concrete, and dropped into the ocean. Even then, I wouldn't
be surprised to see a CERT advisory.
There's no such thing as "only". :)
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 04 Jan 2007 10:27:17 +0000
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Unsecured scripts and site hacking?
Message-Id: <beSdnUJEPLgaSwHYnZ2dnUVZ8sqjnZ2d@bt.com>
Dean G. wrote:
> If they tell you they have no logs at all, but that they know it
> occured via port 80, then they are liars.
It's possible that Alison requested webserver logs, which have gone, but
the ISP has firewall logs from a separate firewall appliance.
However, in Alison's shoes, I'd move to another hosting service.
------------------------------
Date: Thu, 04 Jan 2007 13:18:24 +0100
From: Mirco Wahab <wahab-mail@gmx.de>
Subject: Re: Unsecured scripts and site hacking?
Message-Id: <enirjv$hrt$1@mlucom4.urz.uni-halle.de>
Eric Schwartz wrote:
>> How else would you suggest I upload 50MB weekly updates of adult pornography
>> to my site?
>
> SFTP, scp, HTTPS, just to name three off the top of my head.
rsync over ssh
Regards
M.
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 10116
****************************************
