[17612] in Perl-Users-Digest
Perl-Users Digest, Issue: 5032 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Dec 5 00:05:49 2000
Date: Mon, 4 Dec 2000 21:05:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <975992709-v9-i5032@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 4 Dec 2000 Volume: 9 Number: 5032
Today's topics:
Re: -T & cgi security help with code! (Chris Fedde)
[solved] Re: Error compiling perl, 5.6.0 or 5.7.0 with <david+nntpspam@kalifornia.com>
Re: Can anybody give me any suggestion <jhelman@wsb.com>
Re: Can anybody give me any suggestion <jhelman@wsb.com>
Re: Can anybody give me any suggestion <jhelman@wsb.com>
Re: Can anybody give me any suggestion (Sam Holden)
Re: Can anybody give me any suggestion (Eric Bohlman)
Re: Can anybody give me any suggestion <jhelman@wsb.com>
Re: CGI newbie - premature end of script headers??? (Eric Bohlman)
Re: cgi-lib upload error <me@privacy.net>
Re: cgi-lib upload error <jhelman@wsb.com>
Re: cgi-lib upload error <me@privacy.net>
Re: cgi-lib upload error <jhelman@wsb.com>
Re: Counting bits. <lincmad001@telecom-digest.zzn.com>
Re: dynamic lvalues possible? ber1@my-deja.com
Help listing files in perl punksk8er@home.com
Re: Help with dbm locking requested <bwalton@rochester.rr.com>
kill and security (suid) (Andrew J. Perrin)
Re: learning perl, this does not work ... why? <math_tutor_1@yahoo.com>
Re: newbie question: stopping premature killing of proc <jhelman@wsb.com>
Re: Non-blocking sockets on NT <jhelman@wsb.com>
Re: NT, W95, and open() question (Neil Cherry)
Re: NT, W95, and open() question <jhelman@wsb.com>
Re: passing !~ (Ilya Zakharevich)
Re: PERL limitations and WinNT (w/ MS SQL) question. <jhelman@wsb.com>
Re: read first 4 bytes of file? (Martien Verbruggen)
Re: Serial RS232 Interface (Eric Bohlman)
Re: Two dimensional array to file. <johngros@Spam.bigpond.net.au>
Re: Two dimensional array to file. (Ilya Zakharevich)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 05 Dec 2000 05:04:06 GMT
From: cfedde@fedde.littleton.co.us (Chris Fedde)
Subject: Re: -T & cgi security help with code!
Message-Id: <aH_W5.55$T3.135467008@news.frii.net>
In article <975965854.497075150@news.sonic.net>,
Cynthia Rossbach <cyndie@sonic.net> wrote:
>Hi All,
>(code is below)
>
>The task:
>Write a cgi script that allows users to log in and change their .qmail file.
>This script is for an ISP who wants there clients to be able to come in
>and forward their email or set up the vacation program.
>They're using the QMAIL program so all the users have .qmail files.
>
>sub modify_forward{
> print header, start_html(-title=>'Qmail file', -bgcolor=>'white');
>
> my $user = param('user');
> my $forward_date = param('forward_start_date');
> my $forward_email = param('forward_email');
>
> my $pid;
> defined($pid = open(CHILD_WRITE, "|-")) or Err_Util::error("Can't
>fork:$!\n");
>
> if($pid) { # parent
> print CHILD_WRITE "$forward_email\n";
> close CHILD_WRITE;
> }else{ # child
> my ($name, $passwd, $uid, $gid, $quota, $comment, $gcos, $dir,
>$shell) = getpwnam($user);
> $EUID=$uid;
> $EGID=$gid;
> $ENV{PATH}='/usr/bin:$dir';
> delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
>
> open(QMAIL,">>$dir/.qmail") or print "Can't open $dir/.qmail:$!\n";
> while (<STDIN>){
> print QMAIL "$_";
> }
> close(QMAIL);
> exit;
> }
> print end_html;
>} ## end sub modify_response
There are a few just plain old design issues here. First I'd be writing
this subroutine to be much more independent. That means that it should not
have dependencies on the CGI environment, neither should it be outputing any
HTML.
I don't see the need for the fork. It seems like a lot of work to
go to just to append to a file. If you are going to run as root
just open for append and print.
From a security point of view. Is there a way to re-write this so
that it does not need to be run as user root? For example can
you use group permissions on the .qfile? The routine should
fail if there is no .qfile and if the permissions and ownership
are wrong. It should fail if it tries to update a file for a UID
less than 1000 (or what ever your local admin ceiling is)
It should fail if the path to the .qfile is not trustable.
You might also want to give Randal Schwartz's comments consideration.
chris
--
This space intentionally left blank
------------------------------
Date: Mon, 04 Dec 2000 19:03:39 -0800
From: "david" <david+nntpspam@kalifornia.com>
Subject: [solved] Re: Error compiling perl, 5.6.0 or 5.7.0 with Linux 2.4.0 and glibc 2.2
Message-Id: <gWYW5.127908$w61.90629@dfw-read.news.verio.net>
In article <90h4as$q6n$1@charm.magnus.acs.ohio-state.edu>, "Ilya Zakharevich" <ilya@math.ohio-state.edu> wrote:
> P.S. Looking on your test results, yes, it is broken. op/readdir.t
> and op/stat.t should not fail. Do not know what op/defins.t is doing, but it should not fail either ;-). (OK, it is
> readdir failing again...)
Solved. The problem was header file collisions.
-d
------------------------------
Date: Tue, 05 Dec 2000 02:53:09 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: Can anybody give me any suggestion
Message-Id: <3A2C58AD.26DCDA2C@wsb.com>
iryna martynenko wrote:
>
> Hi everybody.
Greetings.
> Can anybody give me any suggestion how to change the values in the
> hash to a different language
As long as you are doing the translating, rather than expecting Perl to
do it. :)
> %states=(
> 'CA'=>'California',
> 'MT'=>'Montana',
> 'NM'=>'New Mexico',
> );
>
> the associative array works, but if I change the values to Russian or
> any language except English
> like
> %states=(
> 'CA'=>'Калифорния',
> 'MT'=>'Монтана',
> 'NM'=>'Нью Мексика',
> );
>
> the same hash gives message that there is a mistake in the hash
> assignment.
Which version of Perl are you running? (Type perl -v on the command
line if you aren't sure.) The code block you listed doesn't contain any
errors that I can see, and Perl 5.6.0 agrees with me. I won't rule out
that some ancient build of Perl might interpret this as an error, but I
don't see a problem. Specifically, what error message are you getting?
Also, while I'm at it, choosing a somewhat more descriptive subject line
for your posting might help. You would not believe how many messages
are posted in one day with subjects like "Help me please" or "Can
anybody give me a suggestion".
> I will appreciate any suggestions how to solve this problem.
>
>
> Sincerely,
>
> Iryna
>
Hope this helps,
JH
----------------------------------------------------------------
Jeff Helman Product Manager -- Internet Services
jhelman@wsb.com CCH Washington Service Bureau
----------------------------------------------------------------
------------------------------
Date: Tue, 05 Dec 2000 02:56:31 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: Can anybody give me any suggestion
Message-Id: <3A2C595F.FC7B0F62@wsb.com>
Oops. Now that I notice it, your code block does have a problem (though
it compiles under my build of Perl).
Your block was:
%states=(
'CA'=>'Калифорния',
'MT'=>'Монтана',
'NM'=>'Нью Мексика',
);
You should drop that last comma after the value assigned to key 'NM'.
Your block should read:
%states=(
'CA'=>'Калифорния',
'MT'=>'Монтана',
'NM'=>'Нью Мексика'
);
That might solve your problem.
Sorry. Been a long day.
JH
------------------------------
Date: Tue, 05 Dec 2000 02:56:35 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: Can anybody give me any suggestion
Message-Id: <3A2C596D.855DAE57@wsb.com>
Oops. Now that I notice it, your code block does have a problem (though
it compiles under my build of Perl).
Your block was:
%states=(
'CA'=>'Калифорния',
'MT'=>'Монтана',
'NM'=>'Нью Мексика',
);
You should drop that last comma after the value assigned to key 'NM'.
Your block should read:
%states=(
'CA'=>'Калифорния',
'MT'=>'Монтана',
'NM'=>'Нью Мексика'
);
That might solve your problem.
Sorry. Been a long day.
JH
------------------------------
Date: 5 Dec 2000 03:03:48 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Can anybody give me any suggestion
Message-Id: <slrn92omok.gen.sholden@pgrad.cs.usyd.edu.au>
On Tue, 05 Dec 2000 02:56:35 GMT, Jeff Helman <jhelman@wsb.com> wrote:
>Oops. Now that I notice it, your code block does have a problem (though
>it compiles under my build of Perl).
>
>Your block was:
>
>%states=(
> 'CA'=>'Калифорния',
> 'MT'=>'Монтана',
> 'NM'=>'Нью Мексика',
>);
>
>You should drop that last comma after the value assigned to key 'NM'.
>Your block should read:
>
>%states=(
> 'CA'=>'Калифорния',
> 'MT'=>'Монтана',
> 'NM'=>'Нью Мексика'
>);
>
>That might solve your problem.
A trailing comma is perfectly valid.
I use them a lot, since they make adding extra elements very simple.
--
Sam Holden
------------------------------
Date: 5 Dec 2000 03:11:47 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: Can anybody give me any suggestion
Message-Id: <90hmdj$hhl$3@bob.news.rcn.net>
Jeff Helman <jhelman@wsb.com> wrote:
> Oops. Now that I notice it, your code block does have a problem (though
> it compiles under my build of Perl).
> Your block was:
> %states=(
> 'CA'=>'Калифорния',
> 'MT'=>'Монтана',
> 'NM'=>'Нью Мексика',
> );
> You should drop that last comma after the value assigned to key 'NM'.
Nope. Trailing commas in lists get a special dispensation because using
them can make code more maintainable (if you need to add another item to
the end of the list, and the items are on separate lines, you don't need
to change what was previously the last line, something that's very easy to
forget).
------------------------------
Date: Tue, 05 Dec 2000 03:22:18 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: Can anybody give me any suggestion
Message-Id: <3A2C5F83.CA942DF6@wsb.com>
Consider me properly chastened. (The same message goes to Sam Holden
who made the same comment.) Having never used this feature, I was not
aware that it existed. However, since I am not an expert here, how long
has this been a feature? If this was a new addition to say Perl 5.0,
it's possible that this is still causing the error (assuming that the
original poster is still using 4.something, and there are a few of
them). If this has been a feature since the very beginning, I'll shut
up now.
JH
Eric Bohlman wrote:
>
> Jeff Helman <jhelman@wsb.com> wrote:
> > Oops. Now that I notice it, your code block does have a problem (though
> > it compiles under my build of Perl).
>
> > Your block was:
>
> > %states=(
> > 'CA'=>'Калифорния',
> > 'MT'=>'Монтана',
> > 'NM'=>'Нью Мексика',
> > );
>
> > You should drop that last comma after the value assigned to key 'NM'.
>
> Nope. Trailing commas in lists get a special dispensation because using
> them can make code more maintainable (if you need to add another item to
> the end of the list, and the items are on separate lines, you don't need
> to change what was previously the last line, something that's very easy to
> forget).
------------------------------
Date: 5 Dec 2000 02:34:45 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: CGI newbie - premature end of script headers???
Message-Id: <90hk85$hhl$1@bob.news.rcn.net>
jmg2@my-deja.com wrote:
> Thanks for the tip, but I am putting th MIME type at the
> top. As I said, I'm able to cat the output from Perl to
> a file and view the resulting file in a browser ok.
Well, this is really turning into a CGI issue rather than a specifically
Perl issue, so further discussion should really go into
comp.infosystems.www.authoring.cgi; I'm not crossposting there because the
automoderation bot doesn't like crossposts, but feel free to continue the
discussion there.
Given that you can run the script locally and generate an HTML document
that your browser likes, but can't seem to run the script as a CGI
program, you really need to go down to the fundamentals: what's the
difference between the two situations? A couple immediately come to
mind: in the first case, you're the one who's running the script; in the
second case, your Web server is the one running it. The Web server won't
have the same set of permissions as you do, and it likely won't have the
same working directory as you do, so the first thing to look for is any
sort of dependencies on who's running the script. Relative file paths are
warning signs; in a CGI program, they may not be relative to what you
think they are.
Another difference is that when a browser loads a file from the local
filesystem, it tries to guess at the content based on the filename or the
contents of the file itself, whereas when it connects to an HTTP server,
it expects to get a set of headers describing the content before actually
getting the content. And the HTTP server, when it runs a CGI program,
expects to get a set of similar, but not quite identical, headers from the
program. The server error message indicates that the server was able to
start your program, but didn't get a complete set of those headers out of
it. The likely cause is that your program bombed out before it could
finish, or even start, generating those headers. It's also possible that
a logic error in your program prevented it from generating those headers
before trying to deliver the content.
In solving problems of this sort, you really need to keep in mind what
component of the system (the browser, the server, and the CGI program
together form a system) is supposed to do what.
------------------------------
Date: Tue, 05 Dec 2000 02:05:28 GMT
From: "EM" <me@privacy.net>
Subject: Re: cgi-lib upload error
Message-Id: <I3YW5.7156$Nw6.23803@news.iol.ie>
hmm...
correction:
the file uploads fine but still gives the error
maybe i should try to bypass the error html in cgi-lib?
"EM" <me@privacy.net> wrote in message
news:O%XW5.7154$Nw6.23794@news.iol.ie...
> Every file uploads ok except gif and jpeg (even if renamed)
> it gives this error:
>
> cgi-lib.pl: reached end of input while seeking boundary of multipart.
Format
> of CGI input is wrong.
>
>
>
------------------------------
Date: Tue, 05 Dec 2000 02:20:40 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: cgi-lib upload error
Message-Id: <3A2C5112.F8A1F405@wsb.com>
Posting the relevant portions of your script would greatly help. As my
mindreading skills are somewhat rusty, I will defer any assistance until
something substantive is provided.
JH
EM wrote:
>
> hmm...
> correction:
> the file uploads fine but still gives the error
> maybe i should try to bypass the error html in cgi-lib?
>
> "EM" <me@privacy.net> wrote in message
> news:O%XW5.7154$Nw6.23794@news.iol.ie...
> > Every file uploads ok except gif and jpeg (even if renamed)
> > it gives this error:
> >
> > cgi-lib.pl: reached end of input while seeking boundary of multipart.
> Format
> > of CGI input is wrong.
> >
> >
> >
------------------------------
Date: Tue, 05 Dec 2000 03:55:45 GMT
From: "EM" <me@privacy.net>
Subject: Re: cgi-lib upload error
Message-Id: <5HZW5.7170$Nw6.23511@news.iol.ie>
the code i use for uploading is
require "cgi-lib.pl";
my (%cgi_data, # The form data
%cgi_cfn, # The uploaded file(s) client-provided name(s)
%cgi_ct, # The uploaded file(s) content-type(s). These are
# set by the user's browser and may be unreliable
%cgi_sfn, # The uploaded file(s) name(s) on the server (this
machine)
$ret, # Return value of the ReadParse call.
$buf # Buffer for data read from disk.
);
$cgi_lib::writefiles = "$path/temp";
$cgi_lib::maxdata =
99999999999999999999999999999999999999999999999999999999;
binmode(STDIN);
&ReadParse(\%cgi_data,\%cgi_cfn,\%cgi_ct,\%cgi_sfn);
this code however works as in the file is uploaded
however it outputs an error which halts the rest of the script from working
this script works on my windows me computer with apache and activeperl
but when i upload it (i tried webprovider, prohosting, virtualave,
digitalspace, 1stconnection)
the script continues but does not print any output to the browser so its
useless
and it not only hapens with images anymore
it happens with all files, i just assumed it was images because i tested
with exe on my computer
---------
Eric
"EM" <me@privacy.net> wrote in message
news:O%XW5.7154$Nw6.23794@news.iol.ie...
> Every file uploads ok except gif and jpeg (even if renamed)
> it gives this error:
>
> cgi-lib.pl: reached end of input while seeking boundary of multipart.
Format
> of CGI input is wrong.
>
>
>
------------------------------
Date: Tue, 05 Dec 2000 04:14:03 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: cgi-lib upload error
Message-Id: <3A2C6BA5.F81D4E5C@wsb.com>
Ok. Thanks for the additional info. My comments follow.
EM wrote:
>
> the code i use for uploading is
>
> require "cgi-lib.pl";
>
> my (%cgi_data, # The form data
> %cgi_cfn, # The uploaded file(s) client-provided name(s)
> %cgi_ct, # The uploaded file(s) content-type(s). These are
> # set by the user's browser and may be unreliable
> %cgi_sfn, # The uploaded file(s) name(s) on the server (this
> machine)
> $ret, # Return value of the ReadParse call.
> $buf # Buffer for data read from disk.
> );
>
> $cgi_lib::writefiles = "$path/temp";
> $cgi_lib::maxdata =
> 99999999999999999999999999999999999999999999999999999999;
>
> binmode(STDIN);
> &ReadParse(\%cgi_data,\%cgi_cfn,\%cgi_ct,\%cgi_sfn);
Problem. I haven't used cgi-lib in a long time, but as I recall the
ReadParse function takes a typeglob as an argument. Instead you are
specifying a bunch of hash references. This will fail in ways I'm too
tired to discern. Instead, make your script look something like:
&ReadParse(*cgi_data);
Then, depending on the names of your form fields, you could access:
my $FileName = $cgi_data{'file_name'};
my $MIMEType = $cgi_data{'mime_type'};
etc., etc. If you want do do multiple file uploads, just put multiple
fields on your form and parse them accordingly. For example, if you
have a form that includes spaces to add three files, make input fields
with names like FileName1, MIMEType1, FileData1, FileName2, MIMEType2,
etc. Then do a for loop to parse through them:
for (my $i = 1; $i <= 3; $i++) {
my $Filename = $cgi_data{"FileName$i"};
my $MIMEType = $cgi_data{"MIMEType$i"};
my $FileData = $cgi_data{"FileData$i"};
## DO SOMETHING HERE
}
Also, I note that you define a variable ($ret) to grab the return value
from ReadParse, yet you don't actually use it. Try:
$ret = ReadParse(*cgi_input);
and go from there. You also mention that MIME-types set by the browser
are unreliable. I would agree. You might want to explore using the
mime.types config file for Apache to look at trying to determine MIME
types based on file extension. It's not perfect, but it's better than
nothing.
Hope this helps,
JH
------------------------------
Date: Mon, 04 Dec 2000 18:12:24 -0800
From: Linc Madison <lincmad001@telecom-digest.zzn.com>
Subject: Re: Counting bits.
Message-Id: <041220001812243907%lincmad001@telecom-digest.zzn.com>
In article <e5rm2tkt122qs52aq5gl9isfnttua0htj1@4ax.com>, Bart Lateur
<bart.lateur@skynet.be> wrote:
> Wolfgang Hielscher wrote:
>
> >Michael Guenther wrote:
> >> my $count = 0;
> >> while ($str=~/1/g){
> >> $count ++;
> >> }
> >
> >Or simply use m//g in a list context:
> > my $count = @{[$str =~ m/1/g]};
>
> $count = () = $str =~ /1/g;
Isn't it more efficient to say this instead?
my $count = ($str =~ tr/1/1/);
------------------------------
Date: Tue, 05 Dec 2000 03:13:46 GMT
From: ber1@my-deja.com
Subject: Re: dynamic lvalues possible?
Message-Id: <90hmh6$5pd$1@nnrp1.deja.com>
Thanks for the advice and point in the right direction.
I will change the -w to -T and use the hash as suggested.
Bryan
In article <90hedn$8b$1@charm.magnus.acs.ohio-state.edu>,
ilya@math.ohio-state.edu (Ilya Zakharevich) wrote:
> [A complimentary Cc of this posting was sent to Tad McClellan
> <tadmc@metronet.com>],
> who wrote in article <slrn92o7oj.m3f.tadmc@magna.metronet.com>:
> > > my (@names) = $query->param;
> >
> > my %v; # 'v' for 'variables' :-)
>
> my %v_default; # 'v' for 'variables' :-)
>
> > > my ($next) = "\$${value}_default = $query->param
('$value')";
>
> > $v{"${value}_default"} = $query->param($value);
>
> $v_default{$value} = $query->param($value);
>
> </COSMETIC>
>
> Ilya
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 05 Dec 2000 04:36:37 GMT
From: punksk8er@home.com
Subject: Help listing files in perl
Message-Id: <90hrcl$9m3$1@nnrp1.deja.com>
I'm kinda new to perl and I'm kinda lost on how to make a list of files
in a directory.
Can someone be kind enough to show me?
Thank you.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 05 Dec 2000 03:04:22 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Help with dbm locking requested
Message-Id: <3A2C5BDE.4C95EAC0@rochester.rr.com>
James Kufrovich wrote:
...
> I'm having a slight problem with file locking. I'm writing a CGI
> script that has to access a dbm file (MLDBM, since I'm storing complex
> records), and would like to make sure it's locked exclusively whenever
> someone accesses it, or at least when someone writes to it. But, I can't
> for the life of me figure out how to lock the file, and how to make sure
> it's locked. Just to test things, I ran the following script:
> ---------------------------------------------------------
> #!/usr/bin/perl -w
>
> use strict;
> use SDBM_File;
> use MLDBM;
> use Fcntl qw/:flock/;
>
> my %hash1;
> my %hash2;
>
> my $handle1 = tie (%hash1, 'MLDBM', 'testdb.dat', 'O_EXLOCK', 0666)
> or die "Can't open first hash: $!\n";
> sleep 1;
> my $handle2 = tie (%hash2, 'MLDBM', 'testdb.dat', 'O_EXLOCK', 0666)
> or die "Can't open second hash: $!\n";
>
> untie %hash1;
> untie %hash2 if tied %hash2;
> ------------------------------------------------------------------------
>
> hoping the second tie would cause the script to die, as the first tie
> would have locked the file , but apparently O_EXLOCK isn't defined on this
> system. LOCK_EX isn't, either. Neither are O_RWDR or O_CREAT, for that
> matter. And yes, the testdb files do exist already. I sense a config
> problem somewhere, but I don't know where. Is there any way I can find out
> what constants are defined here? Is there any way to make this work? Or
> would it be ok if I were to try flock before tying the dbm file? Hrmm,
> generally, with flock, would I have to write a loop to keeps testing for
> the existence of a lock, like
>
> if (locked) {sleep 1;}
>
> before locking, or does flock (or anything else) do that automatically?
>
> I'm running Perl 5.005_03 on a Redhat 6.0 machine, MLDBM 2.00,
> FreezeThaw 0.41, Storable 1.0.6, and the rest of the modules are what came
> with this Linux distribution/Perl version.
>
> I'd appreciate any help, either posted or emailed. Thanks in
> advance.
>
> Jamie Kufrovich, YAPH wannabe
>
> --
> Egg, eggie@REMOVE_TO_REPLY.sunlink.net
...
Hmmmm...I'm not sure where you got the docs for what you did, but it's
way different than anything I've seen. The best deal, in my opinion, is
to establish a cooperative lock by using a separate local lock file,
which is empty of content. When you have the desired lock on the lock
file, then do all the operations you need to have under lock (like tie,
manuipulate, untie), and then close the lock file's filehandle.
Something like:
use Fcntl qw/:flock/;
...
open LOCK,">lock.file" or die "Oops, $!\n";
flock LOCK,LOCK_EX;
#operations requiring an exclusive lock here
close LOCK;
...
open LOCK,"lock.file" or die "Oops, $!\n";
flock LOCK,LOCK_SH;
#operations requiring shared lock here
close LOCK;
This should work on most systems that support flock or variants thereof
(which excludes, I think, Windoze 9x/ME). Don't forget:
perldoc -q lock
perldoc -f flock
Note that some systems might require the lock file be open for write to
grant an exclusive lock, and open for read to grant a shared lock. Be
sure and read everything you system docs have about flock, fcntl, and
lockf.
Note that in the above flock calls will block until the requested lock
can be granted -- which means your method of testing won't work -- you
need two separate processes running in order to test locking. Fire one
up, establish the lock, and have it wait for a continuation signal (like
pushing enter), fire the other one up and attempt a competing lock, and
observe the second one block until the first one releases its lock
(note: the two processes could be separate instances of the same
program). This method works and is solid -- I've got DBM-type files
which have been in multiprocess continuous use for over five years and
haven't glitched yet using this method of locking. And they worked
without change on three different OS's and several Perl versions.
--
Bob Walton
------------------------------
Date: 04 Dec 2000 23:25:32 -0500
From: aperrin@demog.berkeley.edu (Andrew J. Perrin)
Subject: kill and security (suid)
Message-Id: <87k89ftryb.fsf@nujoma.perrins>
I'm trying to write a little one-off script to solve a problem of
allowing multiple users on different machines to request that a
gateway machine dial up via ppp. Essentially, the script writes a
line to a lockfile; if it's the only line, it also starts pppd. It
then brings up a window (using Tk) with a "Disconnect" button so the
user can remove her lock when done. If it's the last lock, the script
(should) kill any pppd jobs.
That's where the problem comes in. Even though the program is set suid
root (r-sr-sr-x), the pppd processes never get kill()ed. This seems to
happen whether I use:
kill('TERM',$_) foreach (split(/\s+/,$pppds));
or:
system("/bin/kill $_") foreach (split(/\s+/,$pppds));
where $pppds contains a chomp()ed, space-separated list of pppd
processes (of course, usually just one).
No errors are returned, the system just exits quietly. One minor clue
is that kill() does NOT succeed; if I use:
kill 'TERM', $_ and print "Killed $_\n";
I get no output. However, if I just print it:
print "Killing $_\n";
kill 'TERM', $_;
it does print, and I manually issue a /bin/kill -TERM <pid>
immediately thereafter it works fine.
Can anyone advise what I'm doing wrong? Again, this happens even when
running suid, AND even when all pppd processes are owned by the user
running the script.
Environment: debian linux 2.2 (potato), i386 architecture.
Thanks in advance.
--
----------------------------------------------------------------------
Andrew J Perrin - Ph.D. Candidate, UC Berkeley, Dept. of Sociology
Chapel Hill, North Carolina, USA - http://demog.berkeley.edu/~aperrin
aperrin@socrates.berkeley.edu - aperrin@igc.apc.org
------------------------------
Date: Tue, 05 Dec 2000 02:30:04 -0000
From: Mike <math_tutor_1@yahoo.com>
Subject: Re: learning perl, this does not work ... why?
Message-Id: <t2okpc6vdf5if4@corp.supernews.com>
Jerry F. Davis wrote:
>
>
> Hey all:
>
> I am just learning perl. I have perl 5.6.0 for i686-linux
>
> I put in the following script (from Beginning perl by Simon Cozens)
> expecting the $1 .. $5 variables to print something.
> I get the first print line, "The text matches ...", but do not get
> anything for $1 as I expected.
>
> why?
>
> Thanks,
> Jerry
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> $_ = '1: A silly sentence (495,a) *BUT* one which will be useful. (3)';
>
> print "enter a regular expression: ";
> my $pattern = <STDIN>;
> chomp $pattern;
>
> if (/$pattern/) {
> print "The text matches the pattern '$pattern'.\n";
> print "\$1 is '$1'\n" if defined $1;
> print "\$2 is '$2'\n" if defined $2;
> print "\$3 is '$3'\n" if defined $3;
> print "\$4 is '$4'\n" if defined $4;
> print "\$5 is '$5'\n" if defined $5;
> }
> else {
> print "'$pattern' was not found.\n";
> }
Jerry,
After you run the program try an expression like:
enter a regular expression: (silly).+?(495).+?(use\w+)
The parenthesis enable what was matched in them to be stored in the
variables $1, $2 and $3. Good luck.
-Mike
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Tue, 05 Dec 2000 03:51:55 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: newbie question: stopping premature killing of processes when the user presses stop
Message-Id: <3A2C6670.7F56240B@wsb.com>
Luke Lindsay wrote:
>
> I am writing a perl program that processes cgi data. I want to make sure
> that even if the user presses stop, back etc on their browser, the process
> lives
> long enough to complete writing information to disk if it has started doing
> so. I.e. I don't want the user to be able to leave the data stored on the
> disk in an inconsistent state. What is the best way of doing this?
There really is no "best" solution, since we have no idea where in your
script you are writing data to disk. One suggestion is to make sure
that you write everything to disk before you send anything back to the
client. For example:
while ($Something) {
WriteToDisk($Whatever);
}
## ALL DONE WRITING TO DISK -- START BROWSER WRITE HERE
print STDOUT "Content-type: text/html\n\n" or die("User left and we lost
STDOUT");
Of course, this could lead to severe irritation for your users if there
is a good deal of processing required before the write to disk (nobody
likes web pages that take 20 seconds before they start loading). But
this does solve two problems. First, it ensures that the write to disk
takes place before any write to a STDOUT that may no longer exist (if
the user has closed the connection), and thus gives your data a much
better chance of actually getting written. Second, if you can make sure
that the data is written, this will eliminate the problem of the user
clicking a link in your generated page that requires this data before
the data itself is actually written (happens more commonly than you
might think).
If the time required to write this data to disk is your problem (i.e.
you are writing a whole bunch of data a line at a time), you might want
to recode your script to use write() or syswrite() to write the data
faster. I've found that I can syswrite() a couple of megabytes in less
than two seconds and that it's almost an order of magnitude faster than
writing line by line.
> Sorry, I realise this is a rather unfocused question.
As long as my suggestion helps, no problem. I don't like posting
proprietary data either. If it doesn't help, though, you may consider
posting the relevant portions of your script.
> TIA
>
> Luke
Hope this points you in the right direction,
JH
----------------------------------------------------------------
Jeff Helman Product Manager -- Internet Services
jhelman@wsb.com CCH Washington Service Bureau
----------------------------------------------------------------
------------------------------
Date: Tue, 05 Dec 2000 03:41:12 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: Non-blocking sockets on NT
Message-Id: <3A2C63F2.B6BE08C2@wsb.com>
I've had very good success using the IO::Socket and IO::Select modules
available with the standard distribution of Perl. I tried the
setsockopt route and was finding little joy there, so I investigated a
bit and found that the IO:: modules did the trick. It will involve a
bit of recoding, but it turns out that it's actually not all that much.
Hope this helps,
JH
----------------------------------------------------------------
Jeff Helman Product Manager -- Internet Services
jhelman@wsb.com CCH Washington Service Bureau
----------------------------------------------------------------
James Lavery wrote:
>
> We've got a system which communicates extensively with non-blocking
> sockets - this all works fine on Irix.
>
> However, we're having problems making our sockets non-blocking on NT
> clients, as we get the error to the tune of:
>
> 'Your vendor has not defined Fcntl macro F_GETFL...' in fcntl.pm
>
> Looking at previous posts across newsgroups indicates that this is a
> known problem, and the way round it is to use setsockopt.
>
> However, I'm finding it very difficult to discover *how* to use
> setsockopt() to achieve this! Unfortunately, 'man setsockopt' gives no
> joy at all...
>
> Has anyone got an example of how to do this? I've found snippets here
> and there, and C header files socket.h etc., but not enough info to get
> me going...
>
> Thanks,
>
> James Lavery
> MicroSec Ltd
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Tue, 05 Dec 2000 04:14:27 GMT
From: njc@CC47532-A.ewndsr1.nj.home.com (Neil Cherry)
Subject: Re: NT, W95, and open() question
Message-Id: <slrn92oqvp.8ge.njc@CC47532-A.ewndsr1.nj.home.com>
On Mon, 4 Dec 2000 17:52:21 -0500, Tad McClellan wrote:
>Neil Cherry <njc@CC47532-A.ewndsr1.nj.home.com> wrote:
>
>>open( R1, $RFile1) or die "Error opening <$RFile1>\n";
>Err, don't you want an indication of _why_ there was an error?
I was hacking the code pretty quickly, it's really not too bad once
you consider that I'm not a Perl programmer and haven't written a Perl
program before. (I've hacked other programs but never written one
before).
>If so, print the $! special variable in your diag message:
>
> open( R1, $RFile1) or die "Error opening <$RFile1> $!\n";
> ^^
>
>Then see what it says.
I'll give you a hint (I'm not being sarcastic) it doesn't say anything
(???). The program keeps running but the files are not created!
That's why I find this so weird. But I will add the $! as it will be
more informative in the event of a problem.
>Change \ to / for *both* Linux and Windows.
>
>Windows understands /.
>
>Only the command interpreter requires \
Oh, I'll give that a try. I didn't know that.
Thanks
--
Linux Home Automation Neil Cherry ncherry@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
http://linuxha.sourceforge.net/ (SourceForge)
------------------------------
Date: Tue, 05 Dec 2000 04:31:14 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: NT, W95, and open() question
Message-Id: <3A2C6FA4.38315D3B@wsb.com>
Neil Cherry wrote:
>
> I just ran into a problem with NT/W95 (not sure which). When I do:
>
> $RFile1 = ">results\\dlsw7206.$f.txt";
> # :
> open( R1, $RFile1) or die "Error opening <$RFile1>\n";
Two potential problems here (actually, one potential problem and one
suggestion). First (and this is just my humble opinion), I like to keep
the filename separate from the parameters indicating how open() should
operate. For example, by writing:
my $Filename = "test.txt";
## LOTS OF OTHER STUFF
open OUTF, ">>$Filename" or die "Couldn't open $Filename for append";
I know when I read the open call that it was an attempt to append rather
than having to scan back to find out whether the declaration of
$Filename indicated an append-write, an generic (over-)write, a read, a
pipe or something else.
That said, I also notice that you filename is a relative rather than an
absolute path. Thus, your file may indeed be writing, just not where
you expect it to be. You might try using an absolute directory like
"C:/Temp/results/dlsw7206.$f.txt" rather than
"results/dlsw7206.$f.txt". Using the former guarantees where the data
will be written whereas using the latter only tells the interpreter to
find your file relative to the directory in which the Perl interpreter
is currently running.
> It fails to crete the file (dir results exists). If I change the '>' to
> '>>' it creates the file and goes on it's way. Am I missing something
> here? I can get it to work under Linux (except I change '\\' to '/').
This is bizarre. I'm having trouble understanding why you can append
but not create a new file. Does this have something to do with
permissions perhaps? Are you attempting to write to a network or local
drive?
> Thanks
>
> --
> Linux Home Automation Neil Cherry ncherry@home.net
> http://members.home.net/ncherry (Text only)
> http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
> http://linuxha.sourceforge.net/ (SourceForge)
Hope this helps,
JH
----------------------------------------------------------------
Jeff Helman Product Manager -- Internet Services
jhelman@wsb.com CCH Washington Service Bureau
----------------------------------------------------------------
------------------------------
Date: 5 Dec 2000 03:09:52 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: passing !~
Message-Id: <90hma0$2mj$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Abigail
<abigail@foad.org>],
who wrote in article <slrn92nqgs.vnu.abigail@tsathoggua.rlyeh.net>:
> This is in the Cookbook
>
> /^(?!.*)boo/s;
/^ (?! .* boo ) /sx has a better chance to work...
Ilya
------------------------------
Date: Tue, 05 Dec 2000 02:38:44 GMT
From: Jeff Helman <jhelman@wsb.com>
Subject: Re: PERL limitations and WinNT (w/ MS SQL) question.
Message-Id: <3A2C554E.29E0B272@wsb.com>
Rich Parker wrote:
>
> Hello,
Howdy.
> I am doing MS SQL Server queries and returning quite a lot of data
> through a TABLE to the browser (IE or NS, doesn't matter for this). What
> I SEEM (And I emphasize that), to be seeing is some kind of limitation
> where the TABLE (Or page) won't finish and from the browser it just
> appears to HANG (Downloading....).
What happens if you run your script from the command line? Does it hang
or does it complete? I realize that if you are running a CGI you may
need to tweak a bit (such as explicitly providing input values). If the
script hangs from the command line, it is a script problem and the
appropriate debugging steps should be applied. If it does not hang from
the command line, then something else is wrong.
> Is there a CONFIG option I can
> modify, or some other config option (IIS on WinNT) I need to modify to
> get around an issue like this?
Sorry, but I can't answer this. Personally I avoid IIS like the plague,
but this is neither the time nor the place to proselytize on this
point. One quick test, though, would be to install Apache (it's free)
and test under that.
> I am attempting to send about 20K of info
> back to the browser
This is actually not a lot of data. I routinely send hundreds of
megabytes of data to browsers, usually with success. :)
> (Many perl calculations, arrays, etc), and the
> browser just hangs up. I also need to add more fields to the output
> display, so I am worried about limitations, the machine is rather small
> right now (For testing), 550Mhz (Single processor, is that the
> problem?), 130M RAM, nice small server to play with...
For a 20K results set, this is ample. The hundreds of megabytes alluded
to above is generated off of a 200 MHz Pentium with 128 MB of RAM. It
may be slow, but it gets the job done. Again, though, using IIS may
change that.
> Are the bugs I
> am running into machine/hardware related? Or config/software related? Is
> there any changes that can be made to PERL (In some config file
> somewhere) that might solve these issues?
Given what you've told us, your problem could be script related or it
could be machine related. Test the script from the command line and see
what happens. If it hangs there, post the relevant sections and we'll
be glad to help. If it doesn't, I suggest posting a query to one of the
CGI or IIS groups and seeing what they might come up with.
> Thanks for any feedback, use email if necessary.
I hope this helps. Good luck,
JH
----------------------------------------------------------------
Jeff Helman Product Manager -- Internet Services
jhelman@wsb.com CCH Washington Service Bureau
----------------------------------------------------------------
> Rich Parker
> Web Sites:
> Business: http://www.fssi-ca.com
> Personal: http://southcoastdivers.com
> E-mail:
> Business: mailto:RichParker@fssi-ca.com
> Personal: mailto:Rich@southcoastdivers.com
------------------------------
Date: Tue, 05 Dec 2000 02:13:45 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: read first 4 bytes of file?
Message-Id: <slrn92ojpm.nr.mgjv@verbruggen.comdyn.com.au>
On Mon, 04 Dec 2000 21:35:35 GMT,
EM <me@privacy.net> wrote:
> how do i open only the first 4 bytes of a file into memory the files
> i will be dealing with are very large (up to 20MB) and i only need
> the first 4 bytes
You can't 'open' the first 4 bytes only. You open the whole file for
reading, and use read() or sysread() to read the first 4 bytes into a
scalar. Don't worry, opening a large file doesn't use more resources
than opening a small one.
\begin[untested]{code}
open(FOO, 'foo.large') or die $!;
my $little_bit;
my $len = read FOO, $little_bit, 4;
close FOO;
die "Couldn't read 4 bytes. Are you sure that file is large?"
if $len != 4;
# Slightly faster:
open(FOO, 'foo.large') or die $!;
my $little_bit;
my $len = sysread FOO, $little_bit, 4;
close FOO;
die "Couldn't read 4 bytes. Are you really certain it's large?"
if $len != 4;
\end{code}
To be perfectly paranoid, you should check that read or sysread
didn't return undef.
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | values of Beta will give rise to dom!
NSW, Australia |
------------------------------
Date: 5 Dec 2000 02:53:40 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: Serial RS232 Interface
Message-Id: <90hlbk$hhl$2@bob.news.rcn.net>
Wilhelm Amann <amann@t-online.de> wrote:
> knows someone whether and how the serial RS232-Schnittstelle with Perl
> under Linux can be programmed?
use Device::SerialPort;
------------------------------
Date: Tue, 05 Dec 2000 02:14:30 GMT
From: "John Boy Walton" <johngros@Spam.bigpond.net.au>
Subject: Re: Two dimensional array to file.
Message-Id: <acYW5.4308$xW4.40960@news-server.bigpond.net.au>
Thanks Vinny
"Vinny Murphy" <VincentMurphy@mediaone.net> wrote in message
news:m3ofyrpo0k.fsf@vmurphy-hnt1.athome.net...
> Use the Data::Dumper module.
> perldoc Data::Dumper
>
> to dump the data structure you do
>
> print FILEHANDLE Dumper( \@array_of_array);
>
> to get it back you would do an eval on the data in the file.
>
> HTH.
>
> -vjm
>
>
------------------------------
Date: 5 Dec 2000 03:11:15 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Two dimensional array to file.
Message-Id: <90hmcj$2n8$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Vinny Murphy
<VincentMurphy@mediaone.net>],
who wrote in article <m3ofyrpo0k.fsf@vmurphy-hnt1.athome.net>:
> to dump the data structure you do
>
> print FILEHANDLE Dumper( \@array_of_array);
>
> to get it back you would do an eval on the data in the file.
... and this is why one should never use Data::Dumper for
serialization. Use serialization modules, such as FreezeThaw and/or Storable.
Ilya
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 5032
**************************************
