[28586] in Perl-Users-Digest
Perl-Users Digest, Issue: 9950 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 10 14:06:05 2006
Date: Fri, 10 Nov 2006 11:05: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 Fri, 10 Nov 2006 Volume: 10 Number: 9950
Today's topics:
code conversion <shashichinnakar@gmail.com>
code conversion <shashichinnakar@gmail.com>
Re: code conversion <someone@example.com>
Re: Data plotting questions Nov. 2, 2006 <bik.mido@tiscalinet.it>
Re: Data plotting questions Nov. 2, 2006 <bik.mido@tiscalinet.it>
Re: FAQ 6.9 What is "/o" really for? <mark.clementsREMOVETHIS@wanadoo.fr>
Re: FAQ 6.9 What is "/o" really for? <rvtol+news@isolution.nl>
Re: FAQ 6.9 What is "/o" really for? <john@castleamber.com>
Re: FAQ 6.9 What is "/o" really for? <john@castleamber.com>
Re: Generate HTML from a Windows Network Share <scobloke2@infotop.co.uk>
Re: guaranteeing interrupt handling anno4000@radom.zrz.tu-berlin.de
Re: guaranteeing interrupt handling <badarisj@gmail.com>
Re: guaranteeing interrupt handling anno4000@radom.zrz.tu-berlin.de
Re: guaranteeing interrupt handling xhoster@gmail.com
Re: how to source an environment file <ced@blv-sam-01.ca.boeing.com>
Re: Huge Memory Load for reading into memory <tzz@lifelogs.com>
is there a reliable cross-platform method for testing i <simon.chao@gmail.com>
Re: is there a reliable cross-platform method for testi yankeeinexile@gmail.com
Re: is there a reliable cross-platform method for testi (Randal L. Schwartz)
Re: Masking/Hiding a password in Perl Source <craigk@execpc.com>
Re: Masking/Hiding a password in Perl Source <glex_no-spam@qwest-spam-no.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 10 Nov 2006 05:06:53 -0800
From: "Jack" <shashichinnakar@gmail.com>
Subject: code conversion
Message-Id: <1163164013.278345.17180@m7g2000cwm.googlegroups.com>
Hi all
I have a very big file with me thats in EBCDIC format and i
need to convert that into ascii fromat and using dd command i could not
do it completely and only 20 or 30 % of the file is converted and the
rest comes out in the same way...please let me know what best can be
done in perl to fic this
thanks
Jack
------------------------------
Date: 10 Nov 2006 05:06:59 -0800
From: "Jack" <shashichinnakar@gmail.com>
Subject: code conversion
Message-Id: <1163164019.302500.109980@f16g2000cwb.googlegroups.com>
Hi all
I have a very big file with me thats in EBCDIC format and i
need to convert that into ascii fromat and using dd command i could not
do it completely and only 20 or 30 % of the file is converted and the
rest comes out in the same way...please let me know what best can be
done in perl to fic this
thanks
Jack
------------------------------
Date: Fri, 10 Nov 2006 14:26:16 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: code conversion
Message-Id: <c_%4h.51579$P7.10085@edtnps89>
Jack wrote:
>
> I have a very big file with me thats in EBCDIC format and i
> need to convert that into ascii fromat and using dd command i could not
> do it completely and only 20 or 30 % of the file is converted and the
> rest comes out in the same way...please let me know what best can be
> done in perl to fic this
Read the perlebcdic document for information on converting between ASCII and
EBCDIC.
perldoc perlebcdic
John
--
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order. -- Larry Wall
------------------------------
Date: Fri, 10 Nov 2006 15:47:13 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Data plotting questions Nov. 2, 2006
Message-Id: <ap29l2lk114tm7u7o18dep3mpack8ica9t@4ax.com>
On Tue, 07 Nov 2006 12:32:13 GMT, "edgrsprj" <edgrsprj@ix.netcom.com>
wrote:
>I am presently using Perl version 5.8.3.809 from ActiveState with Windows
>XP. If I install the latest version, will that have any significant impact
>on the Perl programs I have already developed?
It shouldn't. There are remote chances of some minor adjustment to be
done.
>For example, I make extensive use of the "GoTo" command. That is probably
It's goto, capitalization *does* matter. You can use pod(-like)
C<goto> to underline that it's a reserved word. In a pure text context
it doesn't make much sense, though, since it's not ambiguous. I'd
reserve the trick for stuff like C<or>.
>not the case for most people writing computer programs. If the latest Perl
Indeed. Since Perl features it, it's officially ok to use it. But it
is a well known bad programming practice, so time permitting I
recommend you to refactor your programs in a way that will avoid it,
unless of course you're talking about magical goto, which is not a
real goto at all, and shouldn't be abused anyway.
>version has eliminated that command then that would have a significant
>impact on my present computer programs. Obviously, without seeing my
That has a virtually null probability. As error prone as a goto is, it
is a basic language feature. Have faith! ;-)
>Finally, I see that ActiveState has versions of several other languages
>available including Python and Tcl. Without getting too technical, can
>anyone explain how they differ from Perl? I am primarily interested in a
All of them (Perl, Python and Tcl) are to some extent inspired by the
shell, and other stuff. IIRC Tcl more than the other two. As far as
Python and Perl are concerned, they're quite different beasts: some
feel more comfortable with the former, some with the latter. In
particular Perl is a free form language while in Python indentation is
part of the syntax. That's why generally Perl aficionados don't like
Python and vice-versa, while they appreciate much more Ruby. Also,
while Perl is strongly based on the TMTOWTDI (multi-)paradigm, in
Python "there must be only one way to do it", and these is another
pair of radically distinctive charachteristics. Of course do not take
all this too seriously, but as a sort of rough indication.
>versatile language which would be easy for scientists to use. Perl is quite
>versatile. But I personally feel that you need a fair amount of programming
>experience to make effective use of it.
I would say that the same applies more or less to any language. As
fare as the "for scientists" detail is concerned, I must say that in
many contexts in this sense efficiency does matter. In which case you
should either switch to something completely different, and lower
level, from Perl or write critical portions of your code in another
language, most probably C.
A friend of mine who does QFT simulations on lattices (IIRC - or
something similar, anyway) even writes his programs in C++, but
performance critical sections of them as Fortran libraries not only
because Fortran is still very popular in Physics, but specifically
because, he claims, it's actually faster. Please note that I don't
want to start a flame here, but he's a knowledgeable guy whose opinion
a priori I respect.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 10 Nov 2006 16:08:22 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Data plotting questions Nov. 2, 2006
Message-Id: <i749l2tmiag2i6rjdnafh7it1q5tcfl2o8@4ax.com>
On Thu, 09 Nov 2006 01:56:11 GMT, "edgrsprj" <edgrsprj@ix.netcom.com>
wrote:
>One of the major goals here is to identify a language which scientists
>around the world would be willing to work with on a variety of projects.
>And some of the important considerations are that the language should be:
I don't think there could ever be such a beast. Or, amongst most
commonly used ones, one that would result to be the "best". As I wrote
in my other post, there are various reasons why Fortran is still very
popular in many scientific environments.
>Versatile
>Reliable
Quite too vague. For reliability, in connection with your stated
target of "scientists" who may not be too experienced programmers, you
may want to use a language that *restricts* your freedom much more
tightly than Perl, e.g. a side effects free one.
>Compatible with programs written in other languages
Again, too vague. What do you mean with "compatible"? If a language
can run external processes, and most common ones do, then it is
somehow compatible with programs written in more or less everything.
If you want a tighter binding, then things may be slightly different.
>Formally supported by some organization such as ActiveState
Huh?!? Why?
Don't misunderstand me: I appreciate AS's work, and have ActivePerl
installed on my Win* boxes, but Perl can live without it. For example,
there's also been pxPerl, which seemed interesting, although I think
it's been more or less abandoned. And there's upcoming
Vanilla/Strawberry Perl.
>Have a support group such as this Perl Newsgroup
I cannot say for other languages, because I don't have specific
experience there, but I bet most have similar ng's and/or fora and/or
ml's, etc.
>Be easy to use
Ah! ease of use, like treaso^Wbeauty, is in the eye of the beholder...
>Be downloadable for free
It is my experience that most common languages, even when there are
commercial implementations, are also available for free.
>Many attractive programs such as different versions of Basic have to be
>purchased. Then their upgrades need to be purchased etc. I personally have
>no objection there. But it would be difficult to get large numbers of other
>scientists around the world to go along with that. Some that I am working
>with do not even want to use Perl in spite of the fact that it is free.
Well, I guess you can't force them to, can you?
>The problem with the fact that Perl is not easy for people who are not
>experienced programmers to use can be overcome if usage instructions are
>prepared which are specifically designed for them. Special modules can also
>be created for them. But if people are going to go through that much
>trouble then it is important to start with the language which is the closest
>to what is needed.
Perl, in its creator's words, is a postmodern, mutiparadigmatic
language, the TMTOWDI-ness of which, in this sense, is part of its
nature. So while we recommend good practices all the time, it's
officially ok to program in a subset of it. Just like when you learn a
new natural language and you don't use *all* of its features from the
beginning, and you mentally translate your mother tongue into it on
the fly. So that if you have, say, a C background it's officially ok
to use C style C<for> loops all the time, although other kinds of flow
control would be often better in various respects.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 10 Nov 2006 14:58:12 +0100
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: FAQ 6.9 What is "/o" really for?
Message-Id: <4554856b$0$27398$ba4acef3@news.orange.fr>
Dr.Ruud wrote:
> John Bokma schreef:
>
>> print if $regex;
>
> ITYM:
>
> print if /$regex/;
>
It works OK if the match is written out longhand.
mark@owl:~$ cat ./testre.pl
#!/usr/bin/perl
use strict;
use warnings;
my $regex = qr/a/;
while(<DATA>){
print $_ if $_ =~ $regex;
}
__END__
Mark
Clements
mark@owl:~$ ./testre.pl
Mark
mark@owl:~$
------------------------------
Date: Fri, 10 Nov 2006 19:07:00 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: FAQ 6.9 What is "/o" really for?
Message-Id: <ej2im6.15k.1@news.isolution.nl>
Mark Clements schreef:
> Dr.Ruud:
>> John Bokma:
>>> print if $regex;
>>
>> ITYM:
>>
>> print if /$regex/;
>
> It works OK if the match is written out longhand.
>
> mark@owl:~$ cat ./testre.pl
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> my $regex = qr/a/;
>
> while(<DATA>){
> print $_ if $_ =~ $regex;
> }
> __END__
Yes, "print if $_ =~ $regex" would do too, because of the "=~" operator:
<quote src="perlop">
Binary "=~" binds a scalar expression to a pattern match. [...]
If the right argument is an expression rather than a search pattern,
substitution, or transliteration, it is interpreted as a search pattern
at run time.
</quote>
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: 10 Nov 2006 18:37:06 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: FAQ 6.9 What is "/o" really for?
Message-Id: <Xns9877805B7A321castleamber@130.133.1.4>
"Dr.Ruud" <rvtol+news@isolution.nl> wrote:
> John Bokma schreef:
>
>> print if $regex;
>
> ITYM:
>
> print if /$regex/;
Yup, oops *bangs head against desk*, thanks.
But question still holds: if this similar to /o, and maybe can this
considered to be more clear, especially to novice users?
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 10 Nov 2006 18:39:50 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: FAQ 6.9 What is "/o" really for?
Message-Id: <Xns987780D2483BBcastleamber@130.133.1.4>
Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr> wrote:
> Dr.Ruud wrote:
>> John Bokma schreef:
>>
>>> print if $regex;
>>
>> ITYM:
>>
>> print if /$regex/;
>>
>
> It works OK if the match is written out longhand.
...
> print $_ if $_ =~ $regex;
...
Yes, my bad, either
... if /$regex/;
or
... if $_ =~ /$regex/;
if $regex is always true in this case.
Thanks Ruud mentioning my slip of the keyboard.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: Fri, 10 Nov 2006 11:37:46 +0000
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Generate HTML from a Windows Network Share
Message-Id: <jpudnbeEke0W-cnYRVnyvg@bt.com>
Michele Dondi wrote:
> On Wed, 08 Nov 2006 17:33:46 +0000, Ian Wilson
> <scobloke2@infotop.co.uk> wrote:
>
>> 1. Use the vertical bar for a high precendence "or".
>
> That would be *bitwise* "or". ITYM C<||>.
Oops! Thanks for the correction.
------------------------------
Date: 10 Nov 2006 12:12:40 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: guaranteeing interrupt handling
Message-Id: <4rj8loFrn9epU1@mid.dfncis.de>
badarisj@gmail.com <badarisj@gmail.com> wrote in comp.lang.perl.misc:
> folks,
>
> the interrupts like INT and QUIT are ignored during the calls to
> 'system'
> builtin. If you have some cleanup code that you DO want executed
> how can we guarantee the execution?
Signal handlers are notoriously unreliable. Any part of the program
can install another one. If you want something executed under all
circumstances don't put it in a signal handler.
> especially this problem would be aggravated if your perl-module
> depends on bunch of other perl-modules -- you would NOT know
> if and when the perl-modules you call are invoking 'system' builtin.
>
> does placing code in DESTROY guarantee the execute with interrupts
> like (INT and QUIT)?
DESTROY is called when an object goes out of scope. How would that
apply? You didn't mention objects so far.
You can use an END block, described in perlmod. That will essentially
be executed whenever the program exits, *except* for uncaught
exceptions, so you need to catch signals you expect and die (or exit)
there.
Anno
------------------------------
Date: 10 Nov 2006 08:18:51 -0800
From: "badarisj@gmail.com" <badarisj@gmail.com>
Subject: Re: guaranteeing interrupt handling
Message-Id: <1163175531.350159.110320@b28g2000cwb.googlegroups.com>
anno4000@radom.zrz.tu-berlin.de wrote:
> badarisj@gmail.com <badarisj@gmail.com> wrote in comp.lang.perl.misc:
> > folks,
> >
> > the interrupts like INT and QUIT are ignored during the calls to
> > 'system'
> > builtin. If you have some cleanup code that you DO want executed
> > how can we guarantee the execution?
>
> Signal handlers are notoriously unreliable. Any part of the program
> can install another one. If you want something executed under all
> circumstances don't put it in a signal handler.
>
> > especially this problem would be aggravated if your perl-module
> > depends on bunch of other perl-modules -- you would NOT know
> > if and when the perl-modules you call are invoking 'system' builtin.
> >
> > does placing code in DESTROY guarantee the execute with interrupts
> > like (INT and QUIT)?
>
> DESTROY is called when an object goes out of scope. How would that
> apply? You didn't mention objects so far.
yep. it wouldn't apply to my current situation.
>
> You can use an END block, described in perlmod. That will essentially
> be executed whenever the program exits, *except* for uncaught
> exceptions, so you need to catch signals you expect and die (or exit)
> there.
i would be catching them... BUT what about some other modules i call
choose to install DEFAULT handlers etc.
it would be the same problem as you note above. right?
how can i guarantee that my callers won't muck with my
signal-catching-setup?
i will check the END and see if that works for me...
thanks,
-badari
>
> Anno
------------------------------
Date: 10 Nov 2006 17:53:12 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: guaranteeing interrupt handling
Message-Id: <4rjsk8Frqn99U1@mid.dfncis.de>
badarisj@gmail.com <badarisj@gmail.com> wrote in comp.lang.perl.misc:
>
> anno4000@radom.zrz.tu-berlin.de wrote:
> > badarisj@gmail.com <badarisj@gmail.com> wrote in comp.lang.perl.misc:
> > > folks,
> > >
> > > the interrupts like INT and QUIT are ignored during the calls to
> > > 'system'
> > > builtin. If you have some cleanup code that you DO want executed
> > > how can we guarantee the execution?
[...]
> > You can use an END block, described in perlmod. That will essentially
> > be executed whenever the program exits, *except* for uncaught
> > exceptions, so you need to catch signals you expect and die (or exit)
> > there.
>
> i would be catching them... BUT what about some other modules i call
> choose to install DEFAULT handlers etc.
> it would be the same problem as you note above. right?
> how can i guarantee that my callers won't muck with my
> signal-catching-setup?
You can't have an absolute guarantee. After all, you can't catch
SIGDIE and some others.
That said, there is a trick to protect sig handlers against being
overwritten. This one does use DESTROY: Bless the sig handler (a
codref) into a class which has a DESTROY method (and probably not
much else). In the destructor do whatever must be done in that
case. (Untested)
$SIG{ INT} = bless sub { die "Caught a SIGINT" }, 'SafeHandler';
sub SafeHandler::DESTROY {
warn "Someone overwrote a sig handler!";
}
Note that DESTROY is called in the normal course of things during
global destruction. So there'd better be a switch to de-fuse it
so it doesn't complain (not shown, should be activated in END {}).
The mechanism will *not* trigger if the overwriting part of the
program keeps a copy of the original (your) handler, for instance
by localizing $SIG{ ...}. This is considered a feature.
I have used this trick occasionally. It's quite a bit of a hassle and
I don't think it has ever caught anything for me. I'd probably not
use it again, but thought I'd mention it.
Anno
------------------------------
Date: 10 Nov 2006 19:00:13 GMT
From: xhoster@gmail.com
Subject: Re: guaranteeing interrupt handling
Message-Id: <20061110140206.703$mh@newsreader.com>
"badarisj@gmail.com" <badarisj@gmail.com> wrote:
> folks,
>
> the interrupts like INT and QUIT are ignored during the calls to
> 'system'
> builtin. If you have some cleanup code that you DO want executed
> how can we guarantee the execution?
What clean up code? If you don't get the signal and hence aren't exiting
due to it, what are you cleaning up?
> especially this problem would be aggravated if your perl-module
> depends on bunch of other perl-modules -- you would NOT know
> if and when the perl-modules you call are invoking 'system' builtin.
The vast majority of modules don't invoke the "system" builtin. And if you
wish to tightly control this sort of thing, then you shouldn't use those
modules which do do so.
>
> does placing code in DESTROY guarantee the execute with interrupts
> like (INT and QUIT)?
No.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 10 Nov 2006 11:15:06 GMT
From: Charles DeRykus <ced@blv-sam-01.ca.boeing.com>
Subject: Re: how to source an environment file
Message-Id: <J8IHx6.1Lv@news.boeing.com>
anno4000@radom.zrz.tu-berlin.de wrote:
> Charles DeRykus <ced@blv-sam-01.ca.boeing.com> wrote in comp.lang.perl.misc:
>> ...
>>>
>> scriptname:
>> export DUM1=foo
>> ..
>>
>> perl -le 'BEGIN{ system(". /path/to/scriptname")== 0 or die "source
>> failed: $?}; use Env; print $ENV{DUM1};'
>
> Did you test that?
>
> Environment variables from .../scriptname will not become available. What
> is "use Env" supposed to do?
Oops, sorry. A comedy of errors works well though if it's late, you
source scriptname before perl comes on the scene, you engage in some
shell sorcery , etc.
--
Charles DeRykus
------------------------------
Date: Fri, 10 Nov 2006 17:16:03 +0000
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Huge Memory Load for reading into memory
Message-Id: <g69ac2zw7cc.fsf@lifelogs.com>
On 7 Nov 2006, David.Squire@no.spam.from.here.au wrote:
> I seem to recall reading here in the last couple of months that there
> *is* indeed an overhead that could do that for hashes (as used above)
> ... something of the order of 60 bytes per entry, independent of the
> size of the key or value. If the keys and values are only a few bytes
> each, then a 10x overhead is not implausible.
OK, so my tip of keeping the data in a string as long as possible
should help. I don't know the exact data the OP used so it's hard to
tell how that will affect performance.
I don't know the relevant internals, but 10x overhead on any kind of
in-memory storage is clearly excessive; it points to either bad data
structure design (the case here) or bad interpreter/VM design. I know
the Perl interpreter is not all that bad with the memory usage, so I
went with the former assumption. But it's not impossible the OP just
had multiple copies of the data inadvertently.
Ted
------------------------------
Date: 10 Nov 2006 08:48:00 -0800
From: "it_says_BALLS_on_your_forehead" <simon.chao@gmail.com>
Subject: is there a reliable cross-platform method for testing if a file is compressed?
Message-Id: <1163177280.237662.236140@b28g2000cwb.googlegroups.com>
I've tried using Solaris's 'file' command, which seems to work ok on my
2 sample files, but on AIX, I get different results for two different
files that are gzipped.
One result reads : gzip (.gz) compressed data
The second is : data or International Language text
both files are gzipped.
...so, I was wondering if there existed a reliable, consistent way of
testing the file_type of a file within Perl that would not vary across
OS.
------------------------------
Date: 10 Nov 2006 11:41:55 -0600
From: yankeeinexile@gmail.com
Subject: Re: is there a reliable cross-platform method for testing if a file is compressed?
Message-Id: <871wobxkpo.fsf@gmail.com>
"it_says_BALLS_on_your_forehead" <simon.chao@gmail.com> writes:
> I've tried using Solaris's 'file' command, which seems to work ok on my
> 2 sample files, but on AIX, I get different results for two different
> files that are gzipped.
>
> One result reads : gzip (.gz) compressed data
> The second is : data or International Language text
>
> both files are gzipped.
>
> ...so, I was wondering if there existed a reliable, consistent way of
> testing the file_type of a file within Perl that would not vary across
> OS.
If you mean "reliable" and "consistent" in the strict sense of the
word, then you are asking for an impossible task. The only option
available is a series of heuristics of variable reliability and
consistency.
Frequently it is possible to say "This file is *NOT* a <foo>" with
absolute certainty.
Thus given
1) files on this filesystem are either <foo>, <bar>, or <baz>
if it isn't a <foo> and it isn't a <bar> then it must be a a <baz>
However, that answer is only as good as the predicate condition.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - lawrenabae@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
------------------------------
Date: 10 Nov 2006 09:45:21 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: "it_says_BALLS_on_your_forehead" <simon.chao@gmail.com>
Subject: Re: is there a reliable cross-platform method for testing if a file is compressed?
Message-Id: <86bqnfyz4e.fsf@blue.stonehenge.com>
>>>>> "it" == it says BALLS on your forehead <simon.chao@gmail.com> writes:
it> ...so, I was wondering if there existed a reliable, consistent way of
it> testing the file_type of a file within Perl that would not vary across
it> OS.
You mean, *besides* File::Mimeinfo, which a simple CPAN search
would have shown you?
If you didn't look, shame on you.
If you *did* look, what's wrong with that module?
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: 10 Nov 2006 06:05:03 -0800
From: "Craig K" <craigk@execpc.com>
Subject: Re: Masking/Hiding a password in Perl Source
Message-Id: <1163167503.250032.235700@i42g2000cwa.googlegroups.com>
This is one way I have been doing this.... it takes the username and/or
password from one of three sources... system environment, command line
argument or runtime prompt.... I did not want to store my passwords
anyware in the script or otherwise in a file as too many nosy folks out
there. If I need to schedule the script, I can supply the username
and passwords on the command line while scheduling.
This script is for TACACS logins but you can modify for whatever
username and or passwords you want to utilize.... obviously.
Hope it may help someone....
if (!defined $ARGV[0])
{
$username = "$ENV{'USER'}";
chomp ($username);
}
else
{
chomp ($username = $ARGV[0]);
}
if (!defined $username)
{
print "Enter your TACACS username: ";
chomp ($username = <STDIN>);
}
if (!defined $ARGV[1])
{
print "\nYou are logged in with or have specified the following
username: [ $username ]. This will be used for your TACACS account.";
print "\nEnter your TACACS password: ";
system('stty', '-echo');
chomp ($userpass = <STDIN>);
system('stty', 'echo');
}
else
{
chomp ($userpass = $ARGV[1]);
}
------------------------------
Date: Fri, 10 Nov 2006 10:16:56 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Masking/Hiding a password in Perl Source
Message-Id: <4554a604$0$10300$815e3792@news.qwest.net>
Craig K wrote:
> [...]
> If I need to schedule the script, I can supply the username
> and passwords on the command line while scheduling.
FYI: Depending on the OS, the password can then be found in the process
table, so it might be available to anyone or any process running a 'ps',
for example.
> This script is for TACACS logins [...]
Whatever that is.
------------------------------
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 9950
***************************************
