[8612] in Perl-Users-Digest
Perl-Users Digest, Issue: 2229 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 1 23:07:25 1998
Date: Wed, 1 Apr 98 20:00:26 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 1 Apr 1998 Volume: 8 Number: 2229
Today's topics:
(Off-topic) Furlongs, fortnights, acres, chains, etc. (Daniel P. B. Smith)
Re: A problem for Perlxs or Perlxstut (Tye McQueen)
Re: File locking (Andrew M. Langmead)
Re: Forking/Children/Data (Jason Gloudon)
Re: gathering EMail address via CGI (Amy Williams)
Re: God Help Us All (was: Re: Sneex having problems) <sowmaster@juicepigs.com>
Re: God Help Us All (was: Re: Sneex having problems) <sneaker@mediaone.net>
Re: God Help Us All (was: Re: Sneex having problems) <sowmaster@juicepigs.com>
Re: HELP !!! - Templates within Perl (Earl Hood)
Re: integer or string ? <eugene@vertical.net>
newbie not able to get input from a flat file <yogeshdamle@hotmail.com>
Re: newbie not able to get input from a flat file <sneaker@mediaone.net>
Re: Overhead created by a lot of file access (Jason Gloudon)
Re: password input (Jason Gloudon)
Re: Public Key Encryption (non pgp) <jhoglund@mirage.skypoint.net>
Re: s/PATTERN/<how to concat here>/g (Michael J Gebis)
Send S-MIME using Perl....Help <ntungdaj@Oleen.com>
Re: System() command questions (Andrew M. Langmead)
Re: System() command questions (Jason Gloudon)
Re: Use of implicit split to @_ is deprecated (Andrew M. Langmead)
Re: Use of implicit split to @_ is deprecated (Jason Gloudon)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 2 Apr 1998 03:27:16 GMT
From: dpbsmith@world.std.com (Daniel P. B. Smith)
Subject: (Off-topic) Furlongs, fortnights, acres, chains, etc.
Message-Id: <Eqro9H.Dw2@world.std.com>
In article <35223271.61604E90@dgb.nl>, Bert Bril <bert@dgb.nl> wrote:
>Daniel P. B. Smith wrote:
>> It was recently pointed out to me that "one furlong per fortnight"
>> is almost exactly 1 centimeter per minute. How's that for useful?
>Is there something wrong here? Is a furlong 201.6 m?
>Or should it be '1 centimeter per hour'?
>In which case a furlong is a more comprehensible 3.36 m.
A furlong is 220 God-given yards. A yard is 36 inches; a meter is 39.37
inches; so, yep, a furlong is 201.168 meters. A mile is exactly eight
furlongs. A furlong is ten chains. So there are 80 chains to a mile,
so a square mile is 6400 square chains = 640 acres, and an acre is ten
square chains. On the other hand, a plot that's a furlong square would
be exactly ten acres.
A furlong is a "furrow-long."
That doesn't quite make sense because a farm plot would be 40 acres, not
ten, so the furrows would be two furlongs long, not one... oh, well...
A mile of course is milia pasuum (I don't think I spelled that right),
a thousand paces...
Hey, I think these are just as good as
one-ten-millionth-the-distance-from-pole-to-equator-measured-inaccurately.
--
Daniel P. B. Smith
dpbsmith@world.std.com
------------------------------
Date: 1 Apr 1998 18:40:02 -0600
From: tye@fohnix.metronet.com (Tye McQueen)
Subject: Re: A problem for Perlxs or Perlxstut
Message-Id: <6fump2$1tc@fohnix.metronet.com>
kfox@pt0204.pto.ford.com (Ken Fox) writes:
) tye@fohnix.metronet.com (Tye McQueen) writes:
) > nisy <ni@aoe.vt.edu> writes:
) >
) > ) I am using C routines called from Perl. I am wondering if arrays
) > ) can be shared across the Perl/C barrier ... which means that arrays
) > ) (double or float) pass from Perl to C and then from C back to Perl
) > ) with new values.
) >
) > Some "facts":
)
) No, these are your opinions. They also happen to be mostly wrong.
Well, we disagree about what we are talking about. It might have
been clearer had I written "Perl code" in place of "Perl" in
several places. To be extra clear, "Perl code" is code written in
the language Perl (big "P") and does not include, for example, C
code that can be called by perl (the program -- little "p") but
is not written in the language Perl.
) > Perl deals with structures that it doesn't create itself as
) > strings (Perl strings are just continguous chunks of memory).
)
) This is one way to do it. Other options include creating a tied
) hash or object to represent your structure.
But this means that "Perl code" has no access to the data in that
structure. It can call C code that can access the data, but the C
code will have to return whatever is asked for by:
1) Copying the data into a buffer that perl allocated.
2) Returning a pointer packed into a buffer that perl allocated.
3) "Cheat" in a manner that is not really supported.
So you've just delayed the problem. Granted, for well-defined
problems, this is often the right way to do it.
But if it is "Perl code" that is to do most of the processing
of the data in the structure and the structure contains a lot
of data, then there isn't a good, efficient solution.
You can make perl use C code and you can do whatever allocation
you want in the C code. You can't use "Perl code" to deal with
stuff not allocated by Perl -- except by writing everything you'd
ever want to do with the stuff in C and having the Perl code call
the C code to have it done.
One way to have the C code "do everything you'd ever want" is to
teach the C code how to split up the data into chunks and combine
chunks back into data and know how to give and take chunks to/from
Perl code. But if you need the whole structure then you're just
copying the whole structure in little pieces instead of in one
piece so I still claim my statement as correct: Perl as a language
(note the capital "P") can't deal with data allocated elsewhere.
It can interface to routines that might have some of their own data
that Perl doesn't really know about, but any data that Perl gets
is going to have to be copied into a buffer that Perl allocated.
We could [I think] and should change this, however.
Doing this works best for "well-defined problems" because you can
predict (or think you can) whatever someone would want to do with
the data as a whole and do that in C and Perl only ever needs to
see small bits of data which are the results of these operations.
) > Perl _insists_ of being the one to malloc(), realloc(), and
) > free() the memory blocks where it stores it strings.
)
) Partially true. You can easily allocate memory and return it back to
) perl as a scalar (IV). Just remember to release it in your DESTROY
) method. [...]
Oops, I never mentioned that case [which can be a common case when
writing XS code]. But Perl code still can't access the data, just
the value of the pointer to the data [and pass that pointer to
other non-Perl code that might access the data].
) > Perl uses pack() to create these strings and unpack() to
) > pull the data our of them.
)
) No. *You* might use pack() but perl doesn't.
Perl code uses pack(). Perl can also call other code that doesn't
use pack(), but _in Perl code_ pack() is about your only choice.
) > A C array of doubles is stored like the output of Perl's
) > pack("d*",@array) ["f*" for floats].
)
) No. *You* might do it this way. A better implementation would use
) a tied array or native perl arrays.
So "a C array of doubles" would be a tied array or native perl
arrays?? This thread started talking about interfacing to
existing C code. When it deals with an array of doubles, it is
_not_ going to be a native perl array, and it is going to be
>>>"stored like"<<< the output of pack("d*",@array). Now you
could write a tied array on top of this that gives Perl code
access to the _elements_ of the array [which I'd much rather write
in Perl code rather than in C code -- but I'll get into this more
later]. You could also copy the array into a native Perl array
[also often better to do in Perl code than in C code].
) > One opinion:
) >
) > Avoid the temptation of having your XS code expect native
) > Perl data structures and using C code to translate that
) > data into a C-friendly format.
)
) Aiee! This is the whole point of XS! The input to XS code *must*
) be built-in Perl data types. The XS code converts these to the
) types required by your C code through either hand-coded conversion
) in your XS code, or through automatic conversion with a typemap.
Yes, I realize that. And it is very good at doing that for very
simple cases. It sucks at doing it for complex cases. All I'm
saying is do the simple stuff in XS and do the complex stuff in
Perl code that calls the XS interfaces. Note that I'm _not_ saying
that the module writer should only do the simple stuff, just that
the module writer should know which parts of the module to write
in C and which parts to write in Perl.
And my strongly held opinion is that the "right stuff" to do in
C is almost always >>>as little as possible<<<.
) > Every case of such code I have seen doesn't scale well:
) > They usually introduce some arbitrary size limits (as
) > dynamic allocation is relatively hard in C, especially when
) > it must talk to Perl).
)
) You might be looking at poor examples. Simple, general typemaps
) can be easily written for arrays. I've posted a few to this
) group already. Here's one:
)
) ------------------------------
) int * T_int_array
)
) INPUT
) T_int_array
) if (SvROK($arg) && SvTYPE(SvRV($arg)) == SVt_PVAV) {
) AV *av = (AV *)SvRV($arg);
) int i = 0, len = AvFILL(av) + 1;
) SV **sv;
) $var = alloca(len * sizeof(int));
) while (i < len) {
) sv = av_fetch(av, i, 0);
) if (sv && SvIOK(*sv)) {
) ${var}[i] = SvIV(*sv);
) }
) else {
) ${var}[i] = 0;
) }
) ++i;
) }
) }
) else {
) croak(\"$var is not an array reference\");
) }
Which I'd wish you'd written as:
sub UserInterface {
my( $array_reference )= @_;
XS_Interface( pack("d*",@$array_ref) );
}
where I could easily enhance it and even debug my enhancements.
And I wouldn't need a C compiler to do any of that.
My interface makes it possible for me to have a huge array already
packed that I can keep sending to this C code over and over again
to have it reused, updated, etc. That sounds like what the
original poster was trying to do since he had huge data structures
that got passsed around multiple times that he didn't want to
waste the time with copying them.
Your interface forces me to translate my prefered data format
(perhaps a packed array because they are huge and I don't mess
with the individual elements much) into a Perl reference to an
ordinary Perl array just so it can go convert it into the format
the C code wants. _Often_ this is a good thing so you should
allow that as I did. However, it can be a very bad thing so you
should allow as much translation as possible to be avoided. This
is done by supporting the native C format in an interface -- like
I did.
And doing it this way is also easier, as you can see by comparing
the code for your solution to the code for my solution. Two
interfaces for less than the price of one.
If you are dealing with C struct's instead of arrays,
then you probably (eventually) want even more interfaces:
XS_Interface( $Packed_struct );
$Packed_struct= pack_it( \@list_of_elements );
set_elements( $Packed_struct, Element_name=>$newValue, ... );
get_elements( $Packed_struct, @list_of_element_names );
# where 0==@list_of_element_names means "all elements"
sub UserInterface {
my( $list_ref )= @_;
XS_Interface( pack_it($list_ref) );
}
And writing pack_it(), etc. may be easier in C or Perl, depending
on a lot of things. But it should not be unconditionally rolled
into the call to XS_Interface().
) If you don't have alloca(), you can allocate a temporary scalar and
) perl will garbage collect it.
Then get one that does this included in the standard distribution
so people stop rolling their own silly ones.
But I still prefer my solution in most cases.
) The main trouble with this is that "int *" is ambiguous. I usually
) use a typedef "int_array" for arrays and reserve "int *" for an
) OUTPUT argument.
Yes, that makes sense.
) > They usually add a costly layer of translation that could be
) > skipped much of the time if a different design was used.
) > They usually are easy to use for simple cases but just
) > plain don't support more complex operations. They are
) > also harder to debug and to enhance.
)
) You're use of pack() and unpack() might add more! Translation isn't
) that costly -- certainly not a big worry for most Perl scripts.
True and true. I, as a module user, just want the choice of when
it matters and when it doesn't. And it is very easy to give me
that choice by writing the tranlation code in Perl so I can
easilly read the *.pm file and figure out how to avoid it (or even
read the module documentation if you had the time to document that
part of it -- you are certainly free to consider that part of it
"internal" if it alllows you to release a useful module sooner).
) Besides, if speed is such an issue, why not just use objects? That
) way you can completely control the memory allocation and the programming
) interface.
I'm not sure I understand your suggestion. But I think you are
saying something close to, "if speed is such an issue, then write
all the work code in C and just call it from Perl via an object
interface". Sometimes that's a good idea, and sometimes speed
is a big issue but resorting to non-trivial C code would be a
bigger problem.
Also, the extra translation doesn't just pose efficiency problems.
Way too many of these translations also limit functionality. For
example, Win32::FilePermissions knows how to translate between
packed Win32 security structs and Perl-friendly hashes with user
names as keys. However, it only does this translation when
converting arguments to some XS code that gets or sets file
permissions. But I want to set permissions on Registry Keys [or
any number of other non-file objects in Win32]. So all that
translation code is useless to me.
When I wrote my Registry interface, I left the slot open for
passing in security information. I had no use for, but there
must be some use for it or it swouldn't be in the C API, right?
I didn't have time to write some fancy translator so I just
pass opaque binary strings around (as far as Perl code is
concerned). Later I realized what I might use those for and
now I can copy permsissions from one Registry key to another
without having to make a single change to my module. If the
writer of Win32::FilePermissions had just separated the Get/Set
code from translate-between-C-and-Perl-data code, then the
two modules could be used together to do all kinds of useful
stuff to Registry key permissions.
But, no. They thought, "why would anyone want that ugly old
packed struct available to the Perl code? I'll be nice and
translate it automatically for them because they will _always_
want me to do that."
And way too many of these fancy XS interfaces have pieces
missing because someone thought it was better to leave out
all mention of some "rarely used" field unless you go to great
effort to translate it into some Perl-friendly data structure.
Or, as happened recently, "why would anyone want to use that
from Perl code?" I don't know but I don't want to stop them
from using it [and without having to go write their own XS
code] just because _I_ haven't figured out a use for it yet.
) > So, use Perl code to generate C-friendly data structures as
) > Perl strings and have your XS code be simple yet robust.
)
) No! This is the worst of all possible solutions. pack() and unpack()
) are clumsy to use and tough to debug.
Not as tough to debug as XS code. I haven't succeeded in
getting a debugger to look at XS code despite a few days
trying. I know you can debug it on some platforms, but
Perl code is still easier to debug.
But _complicated_ pack()/unpack() stuff is sometimes better
written in C [I haven't found a perfect solution for this --
they all seem too complicated too much of the time]. Just don't
write it as XS auto-convert stuff and it will be more useful and
easier to debug [I can test the convert code separate from the
call to the C code].
) You're "simplifying" the XS
) writer's job, but making the user's job *much* harder.
For complicated translations, the (initial) user of the XS code is
the module writer and I'd say I'm making the XS code writing
*much* simpler and making the *.pm code writing *slightly* harder.
) You're also
) making it nearly impossible to enable perl to validate any of the data
) going into your XS code. Script writers generally don't like it when
) perl dumps core...
Well, core dumps is were I _do_ resort to extra XS code. See
Win32API::Registry for examples. My interface prevents Perl from
dumping core but lets you use the full power of the underlying C
interface [including generating a core dump if that C interface is
poorly written]. The heart of my interface is doing the same
things that sysread() does.
) > If the C code insists on giving back pointers to memory that
) > it allocated, then there is no simple way to interface Perl
) > to it. So let Perl allocate all structures.
) >
) > The Perl code would look something like:
) >
) > @perl_array= ( 1.2, 3.4, 5.6 );
) > $packed_array= pack( "d*", @perl_array );
) > some_XS_routine( $packed_array );
) > # Elements of $packed_array can be overwritten by above.
) > @new_array= unpack( "d*", $packed_array );
)
) You've got to be kidding.
)
) How about this code:
)
) @new_array = some_XS_routine(1.2, 3.4, 5.6);
)
) That sure is a lot easier to use.
No. Mine is just as easy to use:
@new_array= user_interface(1.2, 3.4, 5.6);
It just exposes the harder-to-use XS interface *as well* so
that, as the original poster requested, you can avoid the
costly [for large chunks of data] translation when you need
to.
) The XS code for this is not trivial, but certainly not hard.
And the Perl code for this _is_ trivial -- 4 lines.
) You can write a typemap or use macros to make it even easier.
And you can write Perl code and make it even easier still.
[...]
) The function xt_build_output_arg_list() is pretty simple too:
[...]
) I wish I had time to throw together an example for an array of floats
) instead of these complex X Toolkit structures.
If you did it my way, you could have. :)
--
Tye McQueen Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)
------------------------------
Date: Thu, 2 Apr 1998 03:30:56 GMT
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: File locking
Message-Id: <EqroFL.GrG@world.std.com>
prn@bsu.edu (Paul Neubauer) writes:
>It appears that the "normal" idiom for locking would go something like:
> open FH, ">$filename" or die("can't open $filename : $!");
> flock (FH, LOCK_EX);
> ...print stuff to file ...
> flock (FH, LOCK_UN);
> close FH;
>But it seems (and yes, I do understand that I may be putting my foot
>firmly into my mouth) that this could suffer from the same potential
>problems as the code (that one might use as an "alternative" to flock) in
>perlfaq6 where it says:
Its not quite "normal", it has one or two mistakes that prevent it
from working correctly. The item that is definitely a mistake is the
mode the file is opened in. You probably want to use read/write
access.
open FH, "+<$filename" or die("can't open $filename : $!");
This way, If one program has opened the file and has been granted the
lock, and another tries to open the file, it doesn't erase its
contents. It will open the file without modifying the contents, but
when it tries to get the lock, it will be blocked.
Then after receiving the lock, the program will probably want to use
seek() and maybe truncate() to mimic what would of happened if the
file was simply opened in write mode.
Unlocking the file is uncessary, and potentially dangerous. If you
program is buffering data (as will happen with perl, unless you turn
autoflush on for that filehandle) the last write will not be done on a
locked file. The proper protocol is to simply close the file. Any
locks are automaticaly removed when a file is closed. Since many
people expected a lock to have to be matched with an unlock operation,
later versions of perl automatically flush programs file buffers
when flock is called with the LOCK_UN argument.
For more about flocking, see
<URL:http://www.stonehenge.com/merlyn/WebTechniques/col04.html>
>I understand that this may turn out to be more an OS question (the OS in
>question would be Solaris 2.6) than a perl question, but what do folks
>think about this, which corresponds to the atomic lockfile creation
>above:
> sysopen(FH, $filename, O_WRONLY|O_EXCL|O_TRUNC, 0644)
> or die("can't open $filename : $!");
>as a possibly preferable alternative to the "normal" code fragment with
>flock() above? Would this be better?
As the FAQ says, this has problems under NFS. If your program crashes
unexpectadly, your lockfile will hang around, but a kernel lock will
be removed for you. Also, you have the overhead of your locking flag
being an entirely different file on the filesystem. I'd assume a
"lockfile" has more overhead than a lock on a file.
#!/usr/bin/perl -w
use Benchmark;
use Fcntl qw(:DEFAULT :flock);
use strict;
use vars qw($lock_file $counter_file $mode);
$lock_file = 'lock.file';
$counter_file = 'counter.file';
$mode = O_WRONLY|O_EXCL|O_CREAT;
timethese(1000, {
lockfile => << 'EOC',
sysopen(LOCK, $lock_file, $mode, 0644)
or die("can't open $lock_file : $!");
open FILE, ">>$counter_file" or die "Can't open $counter_file: $!";
print FILE $counter++,"\n";
close FILE;
close LOCK;
unlink $lock_file;
EOC
kernelock => << 'EOC'
open FILE, "+<$counter_file" or die "Can't open $counter_file: $!";
flock FILE, LOCK_EX or die "Error getting the lock: $!";
seek FILE, 0, 2;
print FILE $counter++,"\n";
close FILE;
EOC
});
Benchmark: timing 1000 iterations of kernelock, lockfile...
kernelock: 1 secs ( 0.23 usr 0.36 sys = 0.59 cpu)
lockfile: 18 secs ( 0.58 usr 1.86 sys = 2.44 cpu)
--
Andrew Langmead
------------------------------
Date: Thu, 02 Apr 1998 01:58:28 GMT
From: jgloudon@manitoba.bbn.com (Jason Gloudon)
Subject: Re: Forking/Children/Data
Message-Id: <slrn6i5s15.22.jgloudon@manitoba.bbn.com>
Patrick Toal <pat@weslink.ca> wrote:
.
.
>What I want to do is fairly simple. I am writing a perl script that
>will monitor several devices, and grab data from them. I want to run a
>background scan every 60 seconds to check which devices are active
>before I bother trying to get data from them. I want this scan to run in
>a child process from the main program so I don't have to tie up the main
>process waiting. Here's the problem: I need to pass an array back to
>the parent process. I would prefer doing it without the IPC routines,
>and I thought that perhaps perl had some internal way of sharing a
>variable accross processes. I tried passing a reference to the child,
>but that just creates another array in the child.
What types of devices are you trying to "grab data" from ?
Without using IPC via pipes/sockets/files, the only other way to share data,
between two processes in most operating systems is shared memory, whose existing
Perl interface(s) is very muddy, compared to the IPC support.
You didn't say what operating system you were using, but on UNIX-like
environments at least you could solve your problem without IPC by using the
"select RBITS,WBITS,EBITS,TIMEOUT" function, to test for the availability of
data. This is good for most character I/O devices, and all sockets and pipes,
but you did not say what types of devices you were trying to access, or how.
If the device interface you are trying to use does not support select, then you
are most likely using the wrong interface, and if this is the only one available
then the IPC approach with select to read data from the child process is the
only solution available until multi-threaded perl becomes available.
--
Jason Gloudon
------------------------------
Date: Wed, 01 Apr 1998 22:39:37 GMT
From: epic@aros.net (Amy Williams)
Subject: Re: gathering EMail address via CGI
Message-Id: <3522c161.1275205@news.aros.net>
On Wed, 01 Apr 1998 12:14:44 -0800, Glenn Schworak
<Glenn.J.Schworak@state.or.us> wrote:
>Is it posible with perl to ask the uer's browser what their EMail
>address is?
I know for sure it's not in the environment variables, and I can't
think of anything else that's passed by the browser at all. If there
is something besides the eviroment variables then it probably is not
the user's email address.
> chalange you, I was something like this done with java once but
>can't find it again)
If this is true (I know nothing of Java), then there are ways to get
the Java applet and the CGI script to communicate. This is probably
one of the only ways to get the users email address without asking
them directly. Someone please fill me in if I'm wrong.
As far as how to get the Java applet and the CGI script communicating,
you've got me.
--
Amy Williams | Amy Williams Web Page Design
epic@aros.net | and CGI Scripting
http://www.aros.net/~epic/ | http://www.aros.net/~epic/html.html
------------------------------
Date: Wed, 01 Apr 1998 20:57:33 -0500
From: Bob Trieger <sowmaster@juicepigs.com>
To: Sneaker's Nest <sneaker@mediaone.net>
Subject: Re: God Help Us All (was: Re: Sneex having problems)
Message-Id: <3522F08D.1C7D@juicepigs.com>
Sneaker's Nest wrote:
>
> John Porter wrote:
> >
> > And some people wonder "what's so bad about being a newbie".
> >
>
> What's so bad about being a newbie is
> one day I can look forward to being
> an old fart.
>
> A hateful one...
I got the shit beat out of me in the first or second grade for saying
something similar in school. The teacher asked us what we'd like to be
when we grow up and I said "a bitter old man like my father."
Needless to say, the teacher was a bitter old bag and she wrote my
parents a note and made me give it to my parents. It's been 30 odd years
since and I still laugh when I think about it and dad is still "bitter"
about my comment.
--
Bob Trieger | Titanic: big boat, bigger
sowmaster@juicepigs.com | iceberg, big deal
------------------------------
Date: Thu, 02 Apr 1998 02:16:44 GMT
From: Sneaker's Nest <sneaker@mediaone.net>
Subject: Re: God Help Us All (was: Re: Sneex having problems)
Message-Id: <3522F398.48B2@mediaone.net>
Bob Trieger wrote:
> I got the shit beat out of me in the first or second grade for saying
> something similar in school. The teacher asked us what we'd like to be
> when we grow up and I said "a bitter old man like my father."
>
> Needless to say, the teacher was a bitter old bag and she wrote my
> parents a note and made me give it to my parents. It's been 30 odd years
> since and I still laugh when I think about it and dad is still "bitter"
> about my comment.
>
> --
> Bob Trieger | Titanic: big boat, bigger
> sowmaster@juicepigs.com | iceberg, big deal
Dwelling on the past will cause one
to lose track of the future :-)
Sneex
------------------------------
Date: Wed, 01 Apr 1998 21:53:40 -0500
From: Bob Trieger <sowmaster@juicepigs.com>
Subject: Re: God Help Us All (was: Re: Sneex having problems)
Message-Id: <3522FDB4.2B5A@juicepigs.com>
Sneaker's Nest wrote:
> Dwelling on the past will cause one
> to lose track of the future :-)
"Those who don't know history are doomed to repeat it."
--
Bob Trieger | Titanic: big boat, bigger
sowmaster@juicepigs.com | iceberg, big deal
------------------------------
Date: 1 Apr 1998 21:41:35 GMT
From: ehood@medusa.acs.uci.edu (Earl Hood)
Subject: Re: HELP !!! - Templates within Perl
Message-Id: <6fucaf$70m@news.service.uci.edu>
In article <35225A11.462EBF02@horizon.nl>,
T. de Konink <tkonink@horizon.nl> wrote:
>I'm looking for a way of using HTML templates within Perl CGI-scripts,
>so I can isolate HTML-code (for script-output) from the script-source.
>The problem is that the (html-)output contains some variables, which are
>used inside the script.
This can be done in Perl. You can take a look at the Text::Bind
at <URL:http://www.perl.com/CPAN/authors/id/EHOOD/> or the Text::Template
module, also available at CPAN (different author).
--ewh
--
Earl Hood | University of California: Irvine
ehood@medusa.acs.uci.edu | Electronic Loiterer
http://www.oac.uci.edu/indiv/ehood/ | Dabbler of SGML/WWW/Perl/MIME
------------------------------
Date: Wed, 01 Apr 1998 22:47:02 -0500
From: Eugene Sotirescu <eugene@vertical.net>
To: Laurentiu Badea <byte@lmn.pub.ro>
Subject: Re: integer or string ?
Message-Id: <35230A32.1CF1F8BD@vertical.net>
Bitwise operators are less wise than you'd expect: they act BYTEwise on
strings, so you do have to convert to numbers:
$string = "141 255";
$string =~ ~ /([0-9]+)\s+([0-9]+)/i; #why do you use i on digits?
$string =~ /(\d+)\s+(\d+)/; works just fine
($a, $b) = (0 + $1, 0 + $2);
$c = $a & $b;
print "$c\n";
prints 141
Eugene
Laurentiu Badea wrote:
> What am I missing here (I expected 141 and got 041):
> $string = "141 255";
> $string =~ /([0-9]+)\s+([0-9]+)/i;
> ($a,$b) = ($1,$2);
> $c = $a & $b;
> print "$c\n";
>
> Do I really have to add 0 to tell perl it's integers there, can't
> it figure it out since I'm using a bitwise logic operation on them ?
>
> --
> Laurentiu Badea
> mailto:byte@lmn.pub.ro
> http://www2.lmn.pub.ro/~byte/
------------------------------
Date: Wed, 01 Apr 1998 17:11:55 -0800
From: Yogesh Damle <yogeshdamle@hotmail.com>
Subject: newbie not able to get input from a flat file
Message-Id: <3522E5DB.CB6F138D@hotmail.com>
hi!
can anybody help me with this ?
i'm trying to get an input from a flat file and assign it to a variable.
how do i do this ?
thanx in advance.
damle
------------------------------
Date: Thu, 02 Apr 1998 01:28:43 GMT
From: Sneaker's Nest <sneaker@mediaone.net>
Subject: Re: newbie not able to get input from a flat file
Message-Id: <3522E856.6C04@mediaone.net>
Yogesh Damle wrote:
>
> hi!
> can anybody help me with this ?
>
> i'm trying to get an input from a flat file and assign it to a variable.
>
> how do i do this ?
>
> thanx in advance.
>
> damle
one way -
my $stuff = '';
open (flatFile, "pathtofile") || die("I can't, really: $!\n");
while (<flatFile>) {
chomp;
$stuff = $_;
print " Current Line of Stuff is $stuff\n";
}
HTH,
Sneex :-)
------------------------------
Date: Thu, 02 Apr 1998 03:16:14 GMT
From: jgloudon@manitoba.bbn.com (Jason Gloudon)
Subject: Re: Overhead created by a lot of file access
Message-Id: <slrn6i60iv.22.jgloudon@manitoba.bbn.com>
Andrew Boothman <andrew@boothman.easynet.co.uk> wrote:
.
.
>I am writing a CGI script in perl that acts as a hierarchical database
>of web sites, with all sorts of added bit's to make it better than
>Yahoo!
>
>Anyway, the information is stored in semi-colon delimited text files,
>with the name of the category stored on the first line.
In general, any database that depends on text files is not going to scale well.
You should start off using some form of database. eg. GDBM, and you will want
to use persistent CGI in order to avoid the startup costs associated with
starting a new instance of your script for every request.
The CGI related newsgroup under comp.infosystem.www.* would have more specific
answers.
--
Jason Gloudon
------------------------------
Date: Thu, 02 Apr 1998 02:25:57 GMT
From: jgloudon@manitoba.bbn.com (Jason Gloudon)
Subject: Re: password input
Message-Id: <slrn6i5tkm.22.jgloudon@manitoba.bbn.com>
RayG <rgoldber@eb.com> wrote:
>I have a script that prompts for a username and password. It would
>obviously be a good idea if the password were not echoed to the screen. Is
>there a function or module out there that will echo your choice of
>character whenever a character is input? I know there are at least two
>different modules that let you turn echoing off, but I want to echo *'s
>instead.
Use Term::Readkey to enter cbreak mode and read each character yourself using
getc() or ReadKey() and echo the *'s yourself. This mode is somewhat
messy as you have to then deal or not deal with backspace/delete.
Normal UNIX login just uses noecho mode because then it doesn't have to deal
with backspace/delete - the terminal driver does.
--
Jason Gloudon
------------------------------
Date: 2 Apr 1998 02:28:51 GMT
From: Jamie Hoglund <jhoglund@mirage.skypoint.net>
Subject: Re: Public Key Encryption (non pgp)
Message-Id: <6fut53$b9e$1@shadow.skypoint.net>
Andrew Gierth <andrew@erlenstar.demon.co.uk> wrote:
:>>>>> "Tom" == Tom Phoenix <rootbeer@teleport.com> writes:
: Tom> If someone refuses to use pgp, why would they use some other
: Tom> public key encryption? In other words, what reason could someone
: Tom> have which would oppose one and not the other?
: Cost? PGP is not free for commercial users....
Some ISP's refuse to carry it, too. (that and I'm not quite sure how
to import a public key w/out telnet. Though if an ISP doesn't allow
telnet, history has shown they also won't have pgp.)
If it could be done in nothing but perl, it would be:
1.) Free
2.) Portable (well, sort of anyway)
3.) Less of a hassle.
I've contaced RSA for info on a license, but since this is for a freely
distributed script, I want it to be completely functional just like
perl itself, for *free*, thats probably not going to be practical with
anything rsa could provide. (and anyway, they're not getting back to me)
Does anyone know if there an "english" version of that crypto-sig
available anywhere? (does it work?)
As it is, some people are probably replacing pgp with cat. (I have no idea
how often this is being done, but I've "defaulted" to it a number of
times, and warn them of course. )
Ethically, I'm wondering what would be best, provide an "xor" crypt type
of alternative with a warning, or refuse to do anything. Xor (or other
schemes) are misleading where as 'cat' is obviously not encrypted. OTOH,
xor *is* slightly better than nothing if it's actually being used that
way. (if I xor a chunk of data with another chunk of data, allow it to be
"exported" is that illegal?) xor is about the only encryption technique I
can understand.
I'd just refuse to support any ISP that doesn't have pgp, but the people
I deal with don't know if it has pgp or not. (or worse they tell me it
does) So I don't find out until I actually get there, in some cases I've
already done a bunch of custom work for the individual and hate to throw
it all away.
Even though I bring up PGP repeatedly when talking with them so they are
fully aware of the fact that PGP is required, I still hate to ask them to
pay for custom work that winds up being useless to them. (though it really
is their own fault IMO)
A non-pgp, freely distributable solution would be ideal, and I'd feel a
lot better about it. :-)
Jamie
------------------------------
Date: 2 Apr 1998 00:58:04 GMT
From: gebis@albrecht.ecn.purdue.edu (Michael J Gebis)
Subject: Re: s/PATTERN/<how to concat here>/g
Message-Id: <6funqs$2vn@mozo.cc.purdue.edu>
Robert Lopez <Robert.Lopez@abq.sc.philips.com> writes:
}How is string concatenation done on
}the left side of substitution?
}This is what I am trying to do:
} $_ = "STT,31-Mar-98";
} s/(STT,\d\d*\-\w\w*\-)(\d\d)/$1.19.$2/g; #1
} s/\.//g; #2
} $_.="\n";
} print $_;
}I can not figure how to do #1 and #2 in one line.
s/(STT,\d\d*\-\w\w*\-)(\d\d)/${1}19$2/g;
--
Mike Gebis gebis@ecn.purdue.edu mgebis@eternal.net
------------------------------
Date: Wed, 1 Apr 1998 09:30:52 -0500
From: Nuttapong Tungdajahirun <ntungdaj@Oleen.com>
Subject: Send S-MIME using Perl....Help
Message-Id: <E630C877D67BD111B87F00A0C99D934C06C4D9@SSPRING01>
How can I use perl32 send email in S-MIME format?
In our website, we are using perl script that after submit a form it
automatically sends a client's fill-out form info (text format) to our
supplier email address directly. (now using simple formmail.pl )
We would like to send this info in encrypt format (S-MIME).
And should I use Blat, SendMailEx.pm, or Mail::Sender.pm?
Note: Our web is in NT w/ IIS 4.0 and having public key.
Thank you in advance
Jeen
------------------------------
Date: Thu, 2 Apr 1998 02:17:49 GMT
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: System() command questions
Message-Id: <EqrL1q.AKH@world.std.com>
"JC" <khnguyen@comp.uark.edu> writes:
>My problem is, I can't get the "GET /~leeann/list7.htm HTTP/1.0" command to
>execute after the first system command runs.
I think you are slightly mistaken about what system() does. It doesn't
type the next line as you would from the terminal. It runs a program,
in a similar way as if you typed it from a shell. The second line, is
going to the telnet program, not the shell.
So to do what you want to do, the way you want to do it, would be to
start telnet with its input redirected so that you could pass data to
it. Unfortunately, telnet is often implemented in a way to make it
difficult, to do this.
What you really want to do is to get the LWP modules and say:
use LWP::Simple;
getprint 'http://www.richmond.infi.net/~leeann/list7.htm';
If you were using a different program (instead of telnet) which was
implemented so that it read from standard input (instead from its
controlling terminal) you could use perl's piped open feature to pass
data to it.
open ROT13, '| caesar 13' or die;
print ROT13 "GET $GetIdf HTTP/1.0\n\n";
Since telnet is often implemented so that it always reads from its
controlling terminal, to pass data to it, you might need something
like the IO::Expect modoule.
--
Andrew Langmead
------------------------------
Date: Thu, 02 Apr 1998 02:48:17 GMT
From: jgloudon@manitoba.bbn.com (Jason Gloudon)
Subject: Re: System() command questions
Message-Id: <slrn6i5uui.22.jgloudon@manitoba.bbn.com>
JC <khnguyen@comp.uark.edu> wrote:
>Hello. I'm a beginner at perl. I'm trying to retrieve a html file from a
>server using perl.
The easiest way would be to use the perl LWP modules. Which you can find
in CPAN on www.perl.com, which will do exactly what you want.
>Please, any help is appreciated. What is a good Perl book on this subject?
>Thanks.
"Learning Perl" or "Programming Perl".
"Programming Perl" is less accessible if you don't have a lot of programming
experience.
--
Jason Gloudon
------------------------------
Date: Thu, 2 Apr 1998 03:43:49 GMT
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: Use of implicit split to @_ is deprecated
Message-Id: <Eqrp11.2AG@world.std.com>
psf@euclid.jpl.nasa.gov (Peter Scott) writes:
>Is it really necessary for perl to give this warning (with -w)
>when I'm using split in a scalar context? I can trigger this with
>perl -we '$x = split'. I would have thought it should only happen
>in void context? What am I missing?
Are you sure you know what split() does in a scalar context? It
returns the number of fields split, and stores the fields themselves
in the array @_.
It was decided that implicitly scribling over the array that
subroutine parameters are passed in wasn't a good idea.
Are you trying to count the number of fields? If so, why not either
split() into an explicit array and then count the fields, or use the
match operator to count number of occurances of the delimeters (and
add one to get the number of fields)
$x = (@array = split);
If you were trying to get something else, like the first field, then
you might want to take an array slice of the result of split.
$x = (split)[0];
--
Andrew Langmead
------------------------------
Date: Thu, 02 Apr 1998 03:48:05 GMT
From: jgloudon@manitoba.bbn.com (Jason Gloudon)
Subject: Re: Use of implicit split to @_ is deprecated
Message-Id: <slrn6i62el.22.jgloudon@manitoba.bbn.com>
Jonathan Feinberg <jdf@pobox.com> wrote:
>psf@euclid.jpl.nasa.gov (Peter Scott) writes:
>
>> Is it really necessary for perl to give this warning (with -w)
>> when I'm using split in a scalar context? I can trigger this with
>> perl -we '$x = split'.
It gives this warning because as the docs say (man perlfunc) about split:
If not in a list context, returns the number of fields found and splits into
the @_ array.
And as the perldiag manpage says about the warning:
Use of implicit split to @_ is deprecated
(D) It makes a lot of work for the compiler when you
clobber a subroutine's argument list, so it's better
if you assign the results of a split() explicitly to
an array (or list).
I believe this is deprecated because it is easy to unintentionally clobber @_,
which you would most likely not want to do in a subroutine, as that's where
your arguments are.
If you want to count the number of elements returned by split you should say
$x = scalar(@junkarray = split), which says explicitly what you want and what
actually happens.
--
Jason Gloudon
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 2229
**************************************
