[30884] in Perl-Users-Digest
Perl-Users Digest, Issue: 2129 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 15 11:09:49 2009
Date: Thu, 15 Jan 2009 08:09:11 -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, 15 Jan 2009 Volume: 11 Number: 2129
Today's topics:
Re: Arrays instead of files into hashes <tadmc@seesig.invalid>
Re: Circular lists <gamo@telecable.es>
Re: Circular lists <jurgenex@hotmail.com>
Re: Circular lists <cartercc@gmail.com>
Re: how to encrypt password stored in ftp script <cartercc@gmail.com>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <cwilbur@chromatico.net>
Re: set timeout module for Perl <joost@zeekat.nl>
Re: The single biggest STUPIDITY in Perl ... <bernie@fantasyfarm.com>
Re: The single biggest STUPIDITY in Perl ... <tadmc@seesig.invalid>
Re: unable to open file <tadmc@seesig.invalid>
Re: unable to open file <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Jan 2009 05:28:17 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Arrays instead of files into hashes
Message-Id: <slrngmu7eh.esk.tadmc@tadmc30.sbcglobal.net>
Francois Massion <massion@gmx.de> wrote:
> i) When I output @array3 I get a space before each entry
If you are having trouble with output, it is easier to help if
we can actually see the statement that generates the output...
Are you maybe getting a space before each entry *except the first one*?
If so, then remove the double quotes.
perldoc -q space
Why do I get weird spaces when I print an array of lines?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 15 Jan 2009 14:35:56 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Circular lists
Message-Id: <alpine.LNX.2.00.0901151422200.6204@jvz.es>
On Thu, 15 Jan 2009, gamo wrote:
> On Wed, 14 Jan 2009, Xho Jingleheimerschmidt wrote:
>
> > %clist is populated unconditionally. Being a hash, it of course will
> > not have duplicates, but there is nothing to prevent it from having
> > things that are rotations of previous things. So it will end up having
> > them.
> >
>
> The string is tested against %hash, which cointains all the rotations of
> previous unique lists. So, I don't expect there will be duplicates in
> %clist. Note that every unique list as soon as is discovered populates
> %hash with all of it's rotations (from the first).
>
Ok, I rewrote something to assure that there are not duplicates in %clist
and run the test again, with similar results (speed, high use of mem).
The thing could change radically if there is a method to canonicalize all
the rotations of a list in a compact string. Did you say that is possible?
I don't think so. If we have numbers instead of letters, I can't think in
a method that could describe the list of circular numbers in less space
that it has.
Best,
--
http://www.telecable.es/personales/gamo/
"Was it a car or a cat I saw?"
perl -E 'say 111_111_111**2;'
------------------------------
Date: Thu, 15 Jan 2009 05:56:37 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Circular lists
Message-Id: <noeum418rvf16o8sjq58gihurchreied8o@4ax.com>
xhoster@gmail.com wrote:
>It's an XYZ thing. He wants all distinct circular lists that could be made
>with arrangements of those letters. Distinct linear permutations is a
>useful intermediate step in getting there.
Oh, I think I FINALLY understand. The "circular" is not for _generating_
additional results by rotating the list after permutation but it is a
reduction or filter, to _collaps_ multiple lists into one single result,
if those permutated lists are "rotationally equivalent", i.e. if they
can be generated by rotating one of them.
Thank you, thank you, thank you for the explanation.
I'll reread the thread with that clarification in mind.
>> But there are proven and established ways to generate all permutations
>> of a given (multi)-set of items. Why don't those work?
>
>Are any of them on CPAN? I couldn't find any so made a couple of my own.
Maybe
http://search.cpan.org/~edpratomo/Algorithm-Permute-0.12/Permute.pm
It mentions some other permute implementations in a benchmark, too.
However -as others have discussed already- I doubt that it will be very
useful for larger lists (more than 10 to 15 elements) , because the OP
will run out of space and time if he tries to generate all permutations
first and then filter second.
The filter for rotational equivalence has to be incorporated into the
generating algorithm.
jue
------------------------------
Date: Thu, 15 Jan 2009 07:16:46 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: Circular lists
Message-Id: <8f9091e2-e25e-442b-801d-64ae6daf1ba9@p2g2000prf.googlegroups.com>
On Jan 9, 5:45=A0am, gamo <g...@telecable.es> wrote:
> I want to learn an effient way of handle circular lists.
If you want a circular list, you use a counter and modulus it by the
number of items in the list.
For example, if you have a ten element list in an array, and your
counter is modulus ten, 9 gets $array[9], but 10 gets (10 modulus 10 =3D
0) $array[0].
CC
------------------------------
Date: Thu, 15 Jan 2009 07:35:03 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: how to encrypt password stored in ftp script
Message-Id: <83fca8d6-f0a7-4ec1-b150-915543296ab3@13g2000yql.googlegroups.com>
On Jan 13, 8:27=A0pm, Woland99 <wolan...@gmail.com> wrote:
> On Jan 12, 2:07=A0pm, Tim Greer <t...@burlyhost.com> wrote:
>
>
>
> > Woland99 wrote:
> > > Howdy - I want my script to make connection to FTP server and get som=
e
> > > files. I need that script to run everyday automatically on machine
> > > that many people
> > > have access to - but I do not want them to know the username or
> > > password for that
> > > FTP server. Is there a way to save encrypted password with the script
> > > but prevent
> > > people form modifying script to access the FTP server for different
> > > purposes?
>
> > > JT
>
> > FTP is clear text, you can't encrypt it, unless you decrypt somewhere i=
n
> > the process (or on the other end), which probably defeats the purpose,
> > since that's the method someone else would just be able to use anyway.
> > I could only suggest using sftp, scp or rsync over SSH with a trusted
> > key. =A0Of course, the problem is, if people have access to the system,
> > it doesn't matter a whole lot, since the trusted key allows them access
> > without a password. =A0Otherwise, they can see the password in plain
> > text, which means they have the same trusted access once authenticated
> > -- and besides having that access, they have the password as well.
>
> > You can also time it with firewalls to only allow connections from the
> > system to the server at certain times. =A0The best solution, is if you'=
re
> > uploading from the system, is to find the most secure way of doing it,
> > but make it so that the FTP account it uploads to, is separate from
> > anything else (not full or other access to the remote account you
> > upload to). =A0Make it so you can only upload (the files can be hidden
> > from view on the client end once they are uploaded). =A0For the script
> > initiating this, you can try and hide the file name, the job, and also
> > make it so only your user has read permissions on the script used (the
> > last part is the most important -- how are you at risk of others
> > reading the script or being able to log into your account that runs
> > this process? =A0That's the biggest problem you should find a resolutio=
n
> > for). =A0You make it sound like this is a system that anyone can access=
,
> > is that the case? =A0If so, what's stopping people from reading any of
> > your data or modifying that data?
>
> > Ultimately, if this is a system where anyone can access and somehow vie=
w
> > or gain access to the script or password, you should initiate the FTP
> > session (or better yet, a more secure method) from the _server_ side
> > (where you want the files stored) and have it connect to the system and
> > transfer the files _from_ it, which is the best scenario in this case
> > regardless of how people can access it (assuming the other end is more
> > secure). =A0That way, none of the other users on the system you're
> > wanting to transfer files from, will have a way to access the server
> > end. =A0You can do that with trusted keys or some more secure transfer
> > method, but FTP will work fine as well, assuming the server end can be
> > trusted with the same dilemma you have on the system in question.
> > --
> > Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
> > Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
> > and Custom Hosting. =A024/7 support, 30 day guarantee, secure servers.
> > Industry's most experienced staff! -- Web Hosting With Muscle!
>
> Thanks for your comments - indeed the general concerns about data
> security (on top of not giving away FTP login/passwd) are valid -
> basically once I download files from the server I need to provide
> some level of security for it. I do not know much at all about
> security or encryption but my idea for protecting passwd/login
> info in the script was something along the line:
> I would have file containing encrypted password that would be
> generated using encryption key. Using same key I could create
> digital signature of the script that would try to get the password
> out of that file. So everytime I edit the script I would need to
> reset its digital signature in the file contains encrypted password.
> If script comes in and asks for passwd and the digital signature
> of the script (computed at that point) matches the signature that
> was last stored with passwd then it would be give the password
> value. Sorry if that is all gibberish - as I said security and
> encryprions are a bit of new area for me.
Essentially, you need to decide between convenience and security.
Storing a password in any kind of permanent file is inherently
insecure but convenient. Not storing a password is inconvenient but
avoids the risk of unauthorized access to your password file.
At least the file system uses a one way hash to authenticate users,
but one way hashes can be hacked by brute force which is why long
password are better than short ones. With ftp, you don't even have
this option, unless you use a secure connection.
CC
------------------------------
Date: Thu, 15 Jan 2009 06:46:21 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <a4785f0f-849b-4f2c-80a6-273cb3032d94@j38g2000yqa.googlegroups.com>
On Jan 14, 6:34=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at>
> You have never, ever mistyped a file name,
Yes, somewhat frequently.
> started a script in the wrong directory
Never. My invariable habit is to copy all the data files to a task
directory and then write the script in that directory.
> or as the wrong user?
Never. There is only one user on my machine: me.
> Warnings don't catch mistyped filenames. Checking the return value of
> open does.
True. A couple of days ago, I messed up a filehandle. The file opened
all right, there wasn't an error to catch, but nothing got written to
the file. In this case, checking the return value to open didn't catch
the error, and neither did warnings.
> PS: I recall that not so long ago you started a thread with the subject
> "crisis perl".
I did, and I have a story to tell.
My manager (a business type, not an IT type) had a project sitting on
his desk for two weeks. I knew something about it because of overheard
conversations, but I didn't know what it was because no one discussed
it with me. On Thursday, he came into my office to discuss it with me
and told me what he needed, except for the output requirements. I told
him I needed to know how the output was to be structured. Thursday
afternoon, he sent me an Excel file with no further information.
Friday morning, I told him that I thought I could finish the data
extraction part in about ten hours, as I had done something similar,
estimating the time that each piece would take. Friday afternoon he
sent me an email stating that the deadline was THAT FRIDAY (!!!) and
that the output was to be placed in Excel. The Excel file was several
hundred rows deep and about fifty columns wide. He said he wanted it
Monday morning. When I called him to tell him that I couldn't do it in
that time, I learned that he had gone home early that Friday and
couldn't be reached.
I worked until almost midnight that Friday. Saturday I worked from
8:30 a.m. to about 10:30 p.m. Sunday I worked from 3:30 p.m., and
finished around 2:00 a.m. Monday morning. Data extraction took about
ten hours, but creating the Excel file added another 14 hours, for a
total of 24 hours over the weekend.
I didn't mind working. I actually enjoyed doing the project. Also, I
got the credit for finishing the job, which was nice. However, the
code was a piece of crap, undocumented, brittle and not very stable.
When I indicated that I wanted to take a couple of days to clean it
up, I was told not to, that I should not spend any more time on it.
This particular project is an annual job. Guess what's going to happen
next year? And ... if I get tasked with the job again, I'll probably
have to rewrite most of it from scratch.
Question: Are these skills, giving professionals arbitrary and
capricious deadlines totally unrelated to the requirements of the job
at hand and forbidding them from documenting and cleaning up code,
some that's taught in management school, or is it something that
develops on the job?
CC
------------------------------
Date: Thu, 15 Jan 2009 06:54:20 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <58541d8e-5e82-4b27-a886-b53df8f58862@e18g2000vbe.googlegroups.com>
On Jan 14, 8:22=A0pm, Tim Greer <t...@burlyhost.com> wrote:
> I'd imagine it'd be easy enough to figure out in a lot of cases,
> especially if you use unique filehandle names and such, but if you
> didn't and the script grew, it could open the potential for problems to
> crop up that weren't immediately obvious, though I still imagine it
> wouldn't take very long to find the issue. =A0I suppose the issue varies
> upon the risk and how you're using data, how important that data is,
> and how important the results are -- though probably none of those
> things are technically going to increase by not checking the return
> value, it could in some situations (but again, that would be due to
> poor logic in the script anyway, but if we were all perfect, we'd not
> need failures to be reported, let alone return values). =A0I'm certain
> people can (and have) created scripts without good checking that work
> fine and may work fine indefinitely, but it's just easier to
> intentionally put in checks and fail safes as you go along in my
> opinion.
I strikes me that process may have a lot to do with this as well. I
write code incrementally, starting with this:
open INFILE, "<input.txt";
open OUTFILE, ">output.txt";
while (<INFILE>) { print OUTFILE; }
close OUTFILE;
close INFILE;
I then look at the output file. If it's identical to the input file, I
start developing the processing logic. If the output file exists but
is blank, I look for the error. In any case, once this works, I never
have to think about opening or closing the files again.
Obviously, if one were writing a script to be used on a general basis
by others, one would practice defensive programming. In that case, I
would consider the failure to check the call to open as an error.
CC
------------------------------
Date: Thu, 15 Jan 2009 07:11:41 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <33783e7b-fcbc-4603-8e32-26064660b11c@n10g2000vbl.googlegroups.com>
On Jan 15, 12:02=A0am, Peter Scott <Pe...@PSDT.com> wrote:
> You're an accident waiting to happen. =A0When it does, I only hope that y=
ou
> realize that it was a consequence of your poor discipline and not the
> computer victimizing you.
I think you may have missed the context of my comments. When I write a
one-time throw-away script FOR ME to transform some data from one form
to another, I often don't check the return value of open. THIS IS /
NOT/ THE SAME AS PRODUCING CODE FOR OTHERS TO USE! If the script
doesn't work, then I've made an error, so I find the error and fix it.
All I'm saying is that I'm comfortable working this way and find the
consequences acceptable, in part because open is very reliable and
almost never fails.
> If you don't take care with writing programs that are just for you, why
> should anyone trust that you're going to get them right when you're under
> pressure to deliver for someone else?
(1) Because I don't deliver scripts to others that don't include a lot
of defensive programming. This isn't a philosophical stance, but
experiential -- I've spent too much time fixing scripts that break in
the field to deliver something that can be prevented before hand. (2)
In this particular situation, the failure of a call to open, the
problem isn't the script but the failure of the user to move the input
files in the correct directory. And yes, I've been guilty of the
following:
open IN, "<$in" or die "You idiot, you know you need to move $in into
this directory before attempting to run this script!";
CC
------------------------------
Date: Thu, 15 Jan 2009 10:33:00 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: opening a file
Message-Id: <86ljtc37pv.fsf@mithril.chromatico.net>
>>>>> "CC" == cartercc <cartercc@gmail.com> writes:
CC> Question: Are these skills, giving professionals arbitrary and
CC> capricious deadlines totally unrelated to the requirements of
CC> the job at hand and forbidding them from documenting and
CC> cleaning up code, some that's taught in management school, or is
CC> it something that develops on the job?
It's something that happens naturally when "professionals" don't stand
up for themselves. Your boss continues to do it because you allow him
to do it, and it will stop when you stand up to him.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 15 Jan 2009 12:47:32 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: set timeout module for Perl
Message-Id: <873afkdc4r.fsf@zeekat.nl>
Anio <meneldor@gmail.com> writes:
> Thanks for that. I tested it:
> #########
> my @lines = qw/foo bar baz/;
> my @times = qw/0.2 0.25 0.34/;
>
> for (my $i=0; $i<scalar @times; $i++) {
> my $parent = $$;
> unless (my $pid = fork()) {
> select(undef, undef, undef, "$times[$i]");
> kill "USR1",$parent;
> exit();
> }
> }
> $SIG{USR1} = sub {
> print shift @lines, "\n"
> };
> <>; # to keep parent alive
> ###########
> It work very good! But sometimes it exits with "User defined signal 1"
> immediately and i cant understand why. Any ideas?
You have to set $SIG{USR1} *before* fork()ing, since there is no
guarantee that 'kill "USR1",$parent;' is executed before the signal
handler is installed, otherwise.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Thu, 15 Jan 2009 09:10:39 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: The single biggest STUPIDITY in Perl ...
Message-Id: <6tgum4l7i3v3is16ievc269at5lou6fcsu@library.airnews.net>
Uri Guttman <uri@stemsystems.com> wrote:
} but the number of differences are more common:
}
} arrays lists
} ------ -----
} can change size fixed size
} allocated from the heap allocated on the stack
} freed later by freed after expression is done
} garbage collector
} lives between statements lives in a single part of an expression
} can take references no referencing
} can be passed around code can only be used one time
} in its expression
} can be given a name no name is possible
} can make nested trees lists are one dimensional
You left out:
evaluates to # of elements evaluates to last element
in scalar context in scalar context
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Thu, 15 Jan 2009 09:32:40 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: The single biggest STUPIDITY in Perl ...
Message-Id: <slrngmuloo.ib4.tadmc@tadmc30.sbcglobal.net>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Uri Guttman <uri@stemsystems.com> wrote:
>
> } but the number of differences are more common:
> }
> } arrays lists
> } ------ -----
> } can change size fixed size
> } allocated from the heap allocated on the stack
> } freed later by freed after expression is done
> } garbage collector
> } lives between statements lives in a single part of an expression
> } can take references no referencing
> } can be passed around code can only be used one time
> } in its expression
> } can be given a name no name is possible
> } can make nested trees lists are one dimensional
>
> You left out:
> evaluates to # of elements evaluates to last element
> in scalar context in scalar context
Probably because you may have an array in scalar context, but
it is not possible to ever have a list in scalar context.
There IS NO LIST in:
my $foo = (7, 8, 9);
There is only the "comma operator" inside of some parenthesis.
So he left out:
can exist in scalar context never exists in scalar context
:-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 15 Jan 2009 05:00:00 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmu5pg.esk.tadmc@tadmc30.sbcglobal.net>
Tintin@teranews.com <Tintin@teranews.com> wrote:
> Tad J McClellan wrote:
>> Tintin@teranews.com <Tintin@teranews.com> wrote:
>>
>>> Forgot to mention that the standard Perl FindBin module is useful for
>>> working out working directories.
>>
>>
>> No it isn't.
>>
>> It is useful for allowing relative paths in "use lib".
>>
>> It does not help with normal filesystem access.
>
> OK, poorly phrased.
No, not poorly phrased, incorrect.
> What I meant to say is that's it's useful for
> finding out the directory where the script was invoked from as this can
> be used to reference relative paths.
> cat ~/findbin
#!/usr/bin/perl
use warnings;
use strict;
use FindBin qw($Bin);
print "bin=$Bin\n";
> cd ~
> ./findbin
bin=/home/tadmc
> cd /tmp
~/findbin
bin=/home/tadmc
FindBin tells you where the program is.
Where the program is does not matter with regard to relative paths.
Forgot to mention that the standard Perl Cwd module is useful for
working out working directories.
:-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 15 Jan 2009 06:00:35 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <r5gum4te6gmsiltp9c5vuu0vbv6a8243j5@4ax.com>
"Tintin@teranews.com" <Tintin@teranews.com> wrote:
>Tad J McClellan wrote:
>> Tintin@teranews.com <Tintin@teranews.com> wrote:
>>
>>> Forgot to mention that the standard Perl FindBin module is useful for
>>> working out working directories.
>>
>>
>> No it isn't.
>>
>> It is useful for allowing relative paths in "use lib".
>>
>> It does not help with normal filesystem access.
>
>OK, poorly phrased. What I meant to say is that's it's useful for
>finding out the directory where the script was invoked from as this can
>be used to reference relative paths.
No, it can't.
>From perldoc FindBin
>
> $Bin - path to bin directory from where script was invoked
I would rather say poorly worded in the doc. It should say
$Bin - path to the directory, where the script is located
The current wording "from where the script was invoked" could be
missunderstood as the CWD at the time of the script invocation.
jue
------------------------------
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 V11 Issue 2129
***************************************
