[29521] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 765 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 17 11:09:52 2007

Date: Fri, 17 Aug 2007 08:09:11 -0700 (PDT)
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, 17 Aug 2007     Volume: 11 Number: 765

Today's topics:
    Re: Configuring CGI timeouts <harini.gopi@gmail.com>
    Re: DF in HTML <ajit.bakshi@gmail.com>
    Re: DF in HTML <ajit.bakshi@gmail.com>
    Re: Gaa!  UNIX hack tries PPM and fails! anno4000@radom.zrz.tu-berlin.de
    Re: Gaa!  UNIX hack tries PPM and fails! <thepoet_nospam@arcor.de>
        Guitars, tabs, amps and more  airconditi@gmail.com
    Re: How to get "<$myclass_instance>" to work? <socyl@987jk.com.invalid>
    Re: How to get "<$myclass_instance>" to work? <socyl@987jk.com.invalid>
    Re: How to get "<$myclass_instance>" to work? xhoster@gmail.com
        Perl Help  mihirtr@gmail.com
        Rename Perl Process <wogri.wogri@gmail.com>
    Re: Rename Perl Process <jurgenex@hotmail.com>
    Re: Rename Perl Process (Randal L. Schwartz)
    Re: Rename Perl Process <thepoet_nospam@arcor.de>
    Re: Rename Perl Process (Jens Thoms Toerring)
    Re: Rename Perl Process xhoster@gmail.com
    Re: Rename Perl Process (Jens Thoms Toerring)
    Re: Replacing Print Location.. <bill@ts1000.us>
    Re: Replacing Print Location.. <glennj@ncf.ca>
    Re: Replacing Print Location.. <bill@ts1000.us>
        Sending a "status" <bill@ts1000.us>
    Re: Sending a "status" <jurgenex@hotmail.com>
    Re: Sending a "status" <thepoet_nospam@arcor.de>
    Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
    Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 17 Aug 2007 13:23:03 -0000
From:  "harini.gopi@gmail.com" <harini.gopi@gmail.com>
Subject: Re: Configuring CGI timeouts
Message-Id: <1187356983.003096.100010@22g2000hsm.googlegroups.com>

On Aug 14, 8:05 pm, "Petr Vileta" <sto...@practisoft.cz> wrote:
> harini.g...@gmail.com wrote:
> > Hi,
>
> > I have a CGI script wrapped as an exe running on IIS 6.0.  It needs to
> > parse a  31MB file located on a NFS and redirect the output to another
> > CGI script for plotting. It works fine when the file size (that needs
> > to be parsed) is smaller but for larger files it just ends abruptly
> > without further processing. I understand that this could be because
> > the connection timeout for CGI scripts on IIS 6.0 is set to 300 s. But
> > there is no GUI in the IIS properties to edit the same. Can someone
>
> Here _IS_ the tool from M$ ;-) I have Czech version of Windows so the names
> could be little inaccurate ;-)
> Start
>   Setup
>     Control Panels
>       Administration tools (control tools?)
>         Internet Information Service
>
> Go to "Default Web Server" and select "Propreties from menu "Action". Here
> you can change timeout.
> --
>
> Petr Vileta, Czech republic
> (My server rejects all messages from Yahoo and Hotmail. Send me your mail
> from another non-spammer site please.)



Apparantly there is no direct way to edit CGI timeouts in IIS 6.0 as
it involves the modification of the metabase.xml file. However IIS 6.0
resource kit(available from Microsoft downloads) has a utility that
lets configure the timeouts via a GUI instead of having to open the
same on a notepad.  Increasing the timeout did solve the issue.

Harini



------------------------------

Date: Fri, 17 Aug 2007 06:08:33 -0700
From:  sonu <ajit.bakshi@gmail.com>
Subject: Re: DF in HTML
Message-Id: <1187356113.312590.231050@z24g2000prh.googlegroups.com>

On Aug 17, 1:31 pm, use...@DavidFilmer.com wrote:
> On Aug 16, 11:47 pm, sonu <ajit.bak...@gmail.com> wrote:
>
> > <<df>> is disk free command in Unix. I am using Sun OS 5.9.
>
> But it's not controlled by any sort of standards, so the output can be
> different on other systems (or even if you upgrade your own system).
> And sometimes the output can change if strange things happen (very
> large filesystems get added, etc).  Parsing the output of system
> commands can be risky and failure-prone.
>
> I recommend that you access this information using a Perl module such
> ashttp://search.cpan.org/~iguthrie/Filesys-Df-0.92/Df.pm, which will
> allow your program to work on practically any flavor of *NIX for all
> eternity.
>
> Or you can usehttp://search.cpan.org/~iguthrie/Filesys-DfPortable-0.85/DfPortable.pm
> and it will even work on Windows!
>
> --
> The best way to get a good answer is to ask a good question.
> David Filmer (http://DavidFilmer.com)

Thank you for reply.
I will try it.



------------------------------

Date: Fri, 17 Aug 2007 06:25:55 -0700
From:  sonu <ajit.bakshi@gmail.com>
Subject: Re: DF in HTML
Message-Id: <1187357155.733549.263910@z24g2000prh.googlegroups.com>

On Aug 17, 1:31 pm, use...@DavidFilmer.com wrote:
> On Aug 16, 11:47 pm, sonu <ajit.bak...@gmail.com> wrote:
>
> > <<df>> is disk free command in Unix. I am using Sun OS 5.9.
>
> But it's not controlled by any sort of standards, so the output can be
> different on other systems (or even if you upgrade your own system).
> And sometimes the output can change if strange things happen (very
> large filesystems get added, etc).  Parsing the output of system
> commands can be risky and failure-prone.
>
> I recommend that you access this information using a Perl module such
> ashttp://search.cpan.org/~iguthrie/Filesys-Df-0.92/Df.pm, which will
> allow your program to work on practically any flavor of *NIX for all
> eternity.
>
> Or you can usehttp://search.cpan.org/~iguthrie/Filesys-DfPortable-0.85/DfPortable.pm
> and it will even work on Windows!
>
> --
> The best way to get a good answer is to ask a good question.
> David Filmer (http://DavidFilmer.com)

WOW i got my output thanks A ton.......



------------------------------

Date: 17 Aug 2007 10:13:49 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Gaa!  UNIX hack tries PPM and fails!
Message-Id: <5ilamtF3q0aagU1@mid.dfncis.de>

Ayaz Ahmed Khan  <ayaz@dev.null> wrote in comp.lang.perl.misc:
> "usenet@DavidFilmer.com" typed:
> 
> > What I expected to find therein was a file named whatever.ppm that I
> > could run ppm against.  But the tarball contains a directory structure
> > that looks like this:
> > 
> > [.....]
> > drwxrwxrwx   0 0        0 Dec 26 12:20:22 2006 blib/html/site
> > drwxrwxrwx   0 0        0 Dec 26 12:20:22 2006 blib/html
> > -rw-rw-rw-   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt/
> > SSLeay/.exists
> > drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt/
> > SSLeay
> > drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt
> > drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto
> > [.....]
> > 
> > There is no README or anything telling me what to do with this.  Is
> > this a PPM?  Am I supposed to just unroll this somewhere on my Windows
> > box?  Where?  What is this thing?
> 
> Um ...
> 
> $ perl Makefile.PL
> $ make
> # make install
> 
> ... perhaps.

It appears that the tarball contains everything below blib/ and nothing
else.  I don't know how a PPM is supposed to work, but that doesn't look
right.  In any case it won't support a manual install.

Anno


------------------------------

Date: Fri, 17 Aug 2007 12:36:36 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Gaa!  UNIX hack tries PPM and fails!
Message-Id: <46c57a34$0$16109$9b4e6d93@newsspool1.arcor-online.net>

usenet@DavidFilmer.com wrote:
> I'm a UNIX hack, but I want to run Web Scraping Proxy on a Windows box
> that does not have internet access (I'm scraping local pages).  So I
> installed ActivePerl.  So far, so good.
> 
> But WSP needs some old SSLeay crypto modules.  ActiveState doesn't
> supply crypto modules (http://aspn.activestate.com/ASPN/Downloads/
> ActivePerl/PPM/Repository) but they kindly provide a link to the
> University of Winnipeg, specifically mentioning the two modules I
> require (Crypt-SSLeay and Net_SSLeay).
> 
> Since I don't have web access on the target PC then I am looking for a
> PPM file so I can do a local install.
> 
> I found where the plain PPMs are supposedly published:
> http://theoryx5.uwinnipeg.ca/ppms/x86
> 
> And I downloaded the one I need: http://theoryx5.uwinnipeg.ca/ppms/x86/Crypt-SSLeay.tar.gz
> 
> What I expected to find therein was a file named whatever.ppm that I
> could run ppm against.  But the tarball contains a directory structure
> that looks like this:
> 
> [.....]
> drwxrwxrwx   0 0        0 Dec 26 12:20:22 2006 blib/html/site
> drwxrwxrwx   0 0        0 Dec 26 12:20:22 2006 blib/html
> -rw-rw-rw-   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt/
> SSLeay/.exists
> drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt/
> SSLeay
> drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto/Crypt
> drwxrwxrwx   0 0        0 Dec 26 12:19:22 2006 blib/lib/auto
> [.....]
> 
> There is no README or anything telling me what to do with this.  Is
> this a PPM?  Am I supposed to just unroll this somewhere on my Windows
> box?  Where?  What is this thing?
> 
> Can anybody help a poor UNIX hack figure this out?

The .tar.gz you downloaded is the "binary storage" for the ppm package,
holding the modules and scripts belonging to the package, but there is
no such thing as a file with a .ppm extension.

A ppm package consists of a .tar.gz file for the binaries and a .ppd
file ("Perl Package Description", proprietary XML format) with a
description of installation source, namespaces, actions and additional
scripts.

So to install a module offline you usually need the .tar.gz and the
 .ppd, and for most of them you get a zip archive containing those
two for offline installation.

And that's exactly where your problem begins. Normaly you could fetch
an offline version from http://theoryx5.uwinnipeg.ca/ppms/bundles/
and be happy, but due to a number of reasons (export laws concerning
cryptography in the United States of Paranoia, to force the neccessary
disclaimer on the enduser and to follow the bundling prohobitions, and
license issues with SSLeay itself that force all binary distributions
to display credits to the authors) the Crypt::SSLeay binary module
contains an install script that fetches the two library files separately
via the web.

However, there's no restriction you can't work around:

- Download the .tar.gz file (you did that already)

- Open the install_ssl script in your browser at
   http://theoryx5.uwinnipeg.ca/ppms/scripts/install_ssl
   and carefully read the legal disclaimer contained therein

- Download the needed libraries and copy them into the bin directory
   of your target Perl installation
   http://theoryx5.uwinnipeg.ca/ppms/scripts/ssleay32.dll
   http://theoryx5.uwinnipeg.ca/ppms/scripts/libeay32.dll

- Download the package description file from
   http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd and save
   it in the same directory as the .tar.gz, then open it in your
   text editor and change it to read:
<?xml version="1.0" encoding="UTF-8"?>
<SOFTPKG NAME="Crypt-SSLeay" VERSION="0,53,0,0">
   <TITLE>Crypt-SSLeay</TITLE>
   <ABSTRACT>OpenSSL glue that provides LWP https support</ABSTRACT>
   <AUTHOR>Joshua Chamas &lt;josh (at) chamas dot com&gt;</AUTHOR>
   <IMPLEMENTATION>
     <OS NAME="MSWin32" />
     <ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
     <CODEBASE HREF="Crypt-SSLeay.tar.gz" />
     <PROVIDE NAME="Crypt::SSLeay" VERSION="0.51" />
     <PROVIDE NAME="Crypt::SSLeay::Conn" />
     <PROVIDE NAME="Crypt::SSLeay::CTX" />
     <PROVIDE NAME="Crypt::SSLeay::Err" />
     <PROVIDE NAME="Crypt::SSLeay::MainContext" />
     <PROVIDE NAME="Crypt::SSLeay::X509" />
     <PROVIDE NAME="Net::SSL" VERSION="2.77" />
   </IMPLEMENTATION>
</SOFTPKG>

- Open a dos-box in the directory and run "ppm install Crypt-SSLeay.ppd"

HTH
-Chris


------------------------------

Date: Fri, 17 Aug 2007 04:23:57 -0700
From:  airconditi@gmail.com
Subject: Guitars, tabs, amps and more
Message-Id: <1187349837.920239.120140@a39g2000hsc.googlegroups.com>

Reviews of latest models of best guitars, fender, gibson, yamaha, and
many more, with pictures and prices.

http://pro-guitars.blogspot.com/


And if you want to win a free guitar go here

http://freeguitars.blogspot.com/



------------------------------

Date: Fri, 17 Aug 2007 13:32:01 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <fa480h$ra0$1@reader1.panix.com>

In <1187292221.928662.74570@r29g2000hsg.googlegroups.com> Paul Lalli <mritty@gmail.com> writes:

>On Aug 16, 2:29 pm, Uri Guttman <u...@stemsystems.com> wrote:
>> >>>>> "k" == kj  <so...@987jk.com.invalid> writes:
>>
>>   k> In <1187282679.716646.33...@50g2000hsm.googlegroups.com> Paul Lalli <mri...@gmail.com> writes:
>>   >> On Aug 16, 11:34 am, kj <so...@987jk.com.invalid> wrote:
>>   >> I don't know about a CPAN module explicitly, but it's pretty easy for
>>   >> me to create an example.  <> is one of the overloadable operators with
>>   >> the 'overload' pragma:
>>
>>   k> <snip>
>>
>>   k> Thank you very much, and also to Xho.  I hadn't even *thought* of
>>   k> using overload.
>>
>> see my other post. tying is probably even easier than overloading. you
>> just need to create 2 methods that handle the tied interface (a
>> constructor and a readline).

>... uh-huh, and with using overload, you only need the normal
>constructor you were going to have anyway, and ONE method to handle
>the operator.

Actually, as I just discovered, there's another problem with the
overload approach, and that is that the overloaded <> does not
transmit context information properly to the implementing routine.
There's mention of this in the docs.  E.g. the following (incorrectly)
prints "0\n":

  # in package 'main'
  use overload '<>' => sub { print wantarray ? 1 : 0, "\n" };
  my $x = bless +{};
  my @x = <$x>;
  __END__
  0

(This may be have been fixed in more recent versions of overload
I'm using version 1.02).

kj
-- 
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.


------------------------------

Date: Fri, 17 Aug 2007 13:36:48 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <fa489g$ra0$2@reader1.panix.com>

In <x7zm0ri5hu.fsf@mail.sysarch.com> Uri Guttman <uri@stemsystems.com> writes:

>that i didn't see. but as i think it is less work, tying should be on
>the table. maybe he was scared by what he thought it needed.

No, actually, it's not the amount of work that scares, but rather
the fact that I've never gotten the hang of tied variables.  For
me programming with them is always an exercise in trial and error;
I never quite know what to expect.  Too much magic for my little
brain, I guess.

But I will study File::ReadBackwards.  Thanks for the pointer.

kj

-- 
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.


------------------------------

Date: 17 Aug 2007 14:45:53 GMT
From: xhoster@gmail.com
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <20070817104556.410$5y@newsreader.com>

kj <socyl@987jk.com.invalid> wrote:
>
> >... uh-huh, and with using overload, you only need the normal
> >constructor you were going to have anyway, and ONE method to handle
> >the operator.
>
> Actually, as I just discovered, there's another problem with the
> overload approach, and that is that the overloaded <> does not
> transmit context information properly to the implementing routine.

 ...
>
> (This may be have been fixed in more recent versions of overload
> I'm using version 1.02).

The bug warning is still there in the docs for the latest version, 1.06
(corresponding to perl-5.9.5)

Maybe it's time to dig into tie....

But I agree the other poster who suggested

while (defined ($_=$myclass_instance->next())) {

It is uglier than "while (<$mycalss_instance>)", especially the need
to include the define and extra parentheses, but it is less likely
to mislead the code reader into thinking it is a real file handle.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB


------------------------------

Date: Fri, 17 Aug 2007 07:08:39 -0700
From:  mihirtr@gmail.com
Subject: Perl Help
Message-Id: <1187359719.456172.61500@m37g2000prh.googlegroups.com>

Hi,
 I have trying see if it is possible using perl to do following.

I have multiple C/C++ files which I need to go manually and find out
specific function call. I want to check 2nd parameter of this function
(Function_To_Look_For) and get value of it and store it in local file
or output it. For example:

Lets say there is a file named: abc.c It has following contents.

void
MY_CLASS:: Func1()
{

    STRUCT_1_T      my_struct1;
    Function_To_Look_For (MY_1ST_PARAMETER,
                              sizeof( STRUCT_1_T ),
                              MY_3RD_PARAMETER);
}

void
MY_CLASS:: Func2()
{

    STRUCT_2_T  my_struct2;
   Function_To_Look_For (MY_1ST_PARAMETER,
                              sizeof(STRUCT_2_T ),
                              MY_3RD_PARAMETER);

}

After running this script, I want get "sizeof( STRUCT_1_T )" ,
"sizeof(STRUCT_2_T )" as outputs.
I am not sure if this is possible, just wanted to check with experts
on this.


Thanks,



------------------------------

Date: Fri, 17 Aug 2007 06:41:14 -0700
From:  Wolfgang Hennerbichler <wogri.wogri@gmail.com>
Subject: Rename Perl Process
Message-Id: <1187358074.003073.128080@50g2000hsm.googlegroups.com>

Hi perl-people.

I have a process that forks itself by closing the STD[IN|OUT|ERR]
Filehandles, and killing the parent.
This somehow works like this:

close STDIN or die "Can't close STDIN: $!";
close STDERR or die "Can't close STDERR: $!";
close STDOUT or die "Can't close STDOUT: $!";
my $pid=fork();
if ($pid) {
    exit;
}
&error ("can't fork: $!") if not defined $pid;
setsid() or die "Can't start a new Session: $!";

Well, that's cool. Unfortunately this process has a lot of forking to
do, and therefore it would be great (especially for monitoring
reasons) if I could rename the daemons (so that they appear with
different names when I do a 'ps auxc' for example) that fork off. The
OS is Linux 2.6, and I can't find much information about that on the
web. Could you please advise?

Thanks in advance,
wogri



------------------------------

Date: Fri, 17 Aug 2007 13:57:52 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Rename Perl Process
Message-Id: <APhxi.4$6h3.2@trndny05>

Wolfgang Hennerbichler wrote:
> do, and therefore it would be great (especially for monitoring
> reasons) if I could rename the daemons (so that they appear with
> different names when I do a 'ps auxc' for example) that fork off.

'perldoc perlvar' and look out for $0

jue 




------------------------------

Date: Fri, 17 Aug 2007 07:03:12 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Rename Perl Process
Message-Id: <86ps1mb6n3.fsf@blue.stonehenge.com>

>>>>> "Wolfgang" == Wolfgang Hennerbichler <wogri.wogri@gmail.com> writes:

Wolfgang> Well, that's cool. Unfortunately this process has a lot of forking to
Wolfgang> do, and therefore it would be great (especially for monitoring
Wolfgang> reasons) if I could rename the daemons (so that they appear with
Wolfgang> different names when I do a 'ps auxc' for example) that fork off. The
Wolfgang> OS is Linux 2.6, and I can't find much information about that on the
Wolfgang> web. Could you please advise?

"perldoc perlvar"

    $0      Contains the name of the program being executed.

            On some (read: not all) operating systems assigning to $0
            modifies the argument area that the "ps" program sees. On some
            platforms you may have to use special "ps" options or a
            different "ps" to see the changes. Modifying the $0 is more
            useful as a way of indicating the current program state than it
            is for hiding the program you're running. (Mnemonic: same as sh
            and ksh.)

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: Fri, 17 Aug 2007 16:06:33 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Rename Perl Process
Message-Id: <46c5ab6a$0$4526$9b4e6d93@newsspool3.arcor-online.net>

Wolfgang Hennerbichler wrote:
> I have a process that forks itself by closing the STD[IN|OUT|ERR]
> Filehandles, and killing the parent.
> This somehow works like this:
> 
> close STDIN or die "Can't close STDIN: $!";
> close STDERR or die "Can't close STDERR: $!";
> close STDOUT or die "Can't close STDOUT: $!";
> my $pid=fork();
> if ($pid) {
>     exit;
> }
> &error ("can't fork: $!") if not defined $pid;
> setsid() or die "Can't start a new Session: $!";
> 
> Well, that's cool. Unfortunately this process has a lot of forking to
> do, and therefore it would be great (especially for monitoring
> reasons) if I could rename the daemons (so that they appear with
> different names when I do a 'ps auxc' for example) that fork off. The
> OS is Linux 2.6, and I can't find much information about that on the
> web. Could you please advise?

No need to look too far, the answer is in "perldoc perlvar":
Assigning to $0 ($PROGRAM_NAME if "use English;" is in effect) changes
the name that appears in the output of ps.

-Chris


------------------------------

Date: 17 Aug 2007 14:34:44 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Rename Perl Process
Message-Id: <5ilq04F3o9r7qU1@mid.uni-berlin.de>

Wolfgang Hennerbichler <wogri.wogri@gmail.com> wrote:
> I have a process that forks itself by closing the STD[IN|OUT|ERR]
> Filehandles, and killing the parent.
> This somehow works like this:

> close STDIN or die "Can't close STDIN: $!";
> close STDERR or die "Can't close STDERR: $!";
> close STDOUT or die "Can't close STDOUT: $!";

Do you realize that the error message from die can't make it
out anymore since you already closed STDERR?

> my $pid=fork();
> if ($pid) {
>     exit;
> }
> &error ("can't fork: $!") if not defined $pid;
> setsid() or die "Can't start a new Session: $!";

And those error messages also will never appear anywhere since
neither STDOUT nor STDERR are open anymore.

BTW, it looks a bit as if you want to create a daemon, and
the usual way to create one is forking twice (always letting
the parent process exit) and setting a new session in between
the two forks. Moreover, since the setsid() call will make the
process lose its controlling terminal you don't have to expli-
citely close STD(IN|OUT|ERR).

> Well, that's cool. Unfortunately this process has a lot of forking to
> do, and therefore it would be great (especially for monitoring
> reasons) if I could rename the daemons (so that they appear with
> different names when I do a 'ps auxc' for example) that fork off. The
> OS is Linux 2.6, and I can't find much information about that on the
> web. Could you please advise?

It's can't be done via fork() which just (nearly) duplicates your
process. But what you can try is to assign a new value to $0 before
you fork(). I don't think it's guaranteed to work on all UNIX systems
but it seems to work on Linux.
                                 Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de


------------------------------

Date: 17 Aug 2007 14:55:28 GMT
From: xhoster@gmail.com
Subject: Re: Rename Perl Process
Message-Id: <20070817105531.117$Fb@newsreader.com>

jt@toerring.de (Jens Thoms Toerring) wrote:
> Wolfgang Hennerbichler <wogri.wogri@gmail.com> wrote:
> > I have a process that forks itself by closing the STD[IN|OUT|ERR]
> > Filehandles, and killing the parent.
> > This somehow works like this:
>
> > close STDIN or die "Can't close STDIN: $!";
> > close STDERR or die "Can't close STDERR: $!";
> > close STDOUT or die "Can't close STDOUT: $!";
>
> Do you realize that the error message from die can't make it
> out anymore since you already closed STDERR?

Unless the close of STDERR itself failed.

>
> > my $pid=fork();
> > if ($pid) {
> >     exit;
> > }
> > &error ("can't fork: $!") if not defined $pid;
> > setsid() or die "Can't start a new Session: $!";
>
> And those error messages also will never appear anywhere since
> neither STDOUT nor STDERR are open anymore.

It is easy enough to comment out the close for testing purposes.  Why
make it harder by having to comment out the close, then hunt for all the
places that should have had warnings but didn't and add them in?

>
> BTW, it looks a bit as if you want to create a daemon, and
> the usual way to create one is forking twice (always letting
> the parent process exit) and setting a new session in between
> the two forks. Moreover, since the setsid() call will make the
> process lose its controlling terminal you don't have to expli-
> citely close STD(IN|OUT|ERR).

That does not appear to be the case.

perl -wle 'use POSIX; fork and exit; POSIX::setsid(); fork and exit; print
"foo"; warn "bar"'

Both print and warning show up fine.


Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB


------------------------------

Date: 17 Aug 2007 15:04:32 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Rename Perl Process
Message-Id: <5ilro0F3q4okmU1@mid.uni-berlin.de>

xhoster@gmail.com wrote:
> jt@toerring.de (Jens Thoms Toerring) wrote:
> > Wolfgang Hennerbichler <wogri.wogri@gmail.com> wrote:
> > > I have a process that forks itself by closing the STD[IN|OUT|ERR]
> > > Filehandles, and killing the parent.
> > > This somehow works like this:
> >
> > > close STDIN or die "Can't close STDIN: $!";
> > > close STDERR or die "Can't close STDERR: $!";
> > > close STDOUT or die "Can't close STDOUT: $!";
> >
> > Do you realize that the error message from die can't make it
> > out anymore since you already closed STDERR?

> Unless the close of STDERR itself failed.

Well, in that case the program should have died;-)

> > BTW, it looks a bit as if you want to create a daemon, and
> > the usual way to create one is forking twice (always letting
> > the parent process exit) and setting a new session in between
> > the two forks. Moreover, since the setsid() call will make the
> > process lose its controlling terminal you don't have to expli-
> > citely close STD(IN|OUT|ERR).

> That does not appear to be the case.

> perl -wle 'use POSIX; fork and exit; POSIX::setsid(); fork and exit; print
> "foo"; warn "bar"'

> Both print and warning show up fine.

Sorry, you're right. I mis-remembered that they would go away
together with the controlling terminal and didn't double-check.

                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de


------------------------------

Date: Fri, 17 Aug 2007 04:57:17 -0700
From:  Bill H <bill@ts1000.us>
Subject: Re: Replacing Print Location..
Message-Id: <1187351837.762484.77330@50g2000hsm.googlegroups.com>

> I am not proficient in HTTP, but it sounds to me as if you are
> returning a Location response to the web browser from the first
> submission, which requires the browser to send a second HTTP request to
> your second program (I don't believe the server will figure out that
> the Location redirect is to itself), which returns a Location response
> to the browser, which then sends a third HTTP request to the server to
> the first script. Right?

Jim - I was just testing the programs and it appears that my server
may be handling the Print Location. Watching the address line closely
in the browser it never changes till it is done, then it displays the
final program.

FYI here is what the 1st Print Location in program 1 looks like:

print qq~Location: /system/editor/makepdf.pl?project=
$thisproject&folder=$thisfolder&id=$thischapter&whatproject=
$curproject&special=photopage&specvalue1=$updatewhat&specvalue2=
$photolayout\n\n~;


Then the 2nd program (makepdf.pl) uses this one to go back to the 1st
program:

print qq~Location: /system/project.pl?project=
$thisproject&action=editchapter&whatproject=$curproject&editwhat=
$thischapter\n\n~;

So technically I suppose I do not need the Env data in the 2nd program
(or re-running of the 1st program) since all the information needed is
on the command line.

I am wondering, instead considering using exec to run this instead of
the print Location, would it be better to use a system() call? That
way I dont need to have it re-run program 1 when 2 is done, it will
just wait for program 2 to finish and carry on? Is there any drawbacks
to using a system() call to run another perl program (memory, speed
etc)?

Any and all advise is always welcome

Bill H



------------------------------

Date: 17 Aug 2007 13:44:31 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: Replacing Print Location..
Message-Id: <slrnfcb9i0.bpg.glennj@smeagol.ncf.ca>

At 2007-08-17 07:57AM, "Bill H" wrote:
>  I am wondering, instead considering using exec to run this instead of
>  the print Location, would it be better to use a system() call? That
>  way I dont need to have it re-run program 1 when 2 is done, it will
>  just wait for program 2 to finish and carry on? Is there any drawbacks
>  to using a system() call to run another perl program (memory, speed
>  etc)?

You might want to 'do other_prog.pl;'

-- 
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry


------------------------------

Date: Fri, 17 Aug 2007 07:58:34 -0700
From:  Bill H <bill@ts1000.us>
Subject: Re: Replacing Print Location..
Message-Id: <1187362714.154917.30680@d55g2000hsg.googlegroups.com>

On Aug 17, 9:44 am, Glenn Jackman <gle...@ncf.ca> wrote:
> At 2007-08-17 07:57AM, "Bill H" wrote:
>
> >  I am wondering, instead considering using exec to run this instead of
> >  the print Location, would it be better to use a system() call? That
> >  way I dont need to have it re-run program 1 when 2 is done, it will
> >  just wait for program 2 to finish and carry on? Is there any drawbacks
> >  to using a system() call to run another perl program (memory, speed
> >  etc)?
>
> You might want to 'do other_prog.pl;'
>
> --
> Glenn Jackman
> "You can only be young once. But you can always be immature." -- Dave Barry

Glenn that works great!

Bill H



------------------------------

Date: Fri, 17 Aug 2007 06:48:00 -0700
From:  Bill H <bill@ts1000.us>
Subject: Sending a "status"
Message-Id: <1187358480.268317.70710@r29g2000hsg.googlegroups.com>

Using $|++ I have learned that I can "flush" the print buffer to a
browser while perl is doing things, instead of sending all the html
when it is done. Is there any drawbacks to using this in the real
world that any of you may have encountered?

Basically what I would be doing is sending a status to a client while
the perl scripts are working such as (after sending the html headers
and other stuff):

Saving your data...
Processing your data...
Generating completed pdf...
Complete.

etc...

and then sending the ending html data.

Bill H



------------------------------

Date: Fri, 17 Aug 2007 13:55:51 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Sending a "status"
Message-Id: <HNhxi.1$Wr3.0@trndny03>

Bill H wrote:
> Using $|++ I have learned that I can "flush" the print buffer to a
> browser while perl is doing things, instead of sending all the html
> when it is done. Is there any drawbacks to using this in the real
> world that any of you may have encountered?
>
> Basically what I would be doing is sending a status to a client while
> the perl scripts are working such as (after sending the html headers
> and other stuff):
>
> Saving your data...
> Processing your data...
> Generating completed pdf...
> Complete.
>
> etc...
>
> and then sending the ending html data.

Not that you question has anything to do with Perl, but you do realize, that 
the browser is not obligated to display incomplete HTML pages? Many will 
wait until the complete page has been received before beginning to render 
it.

jue 




------------------------------

Date: Fri, 17 Aug 2007 16:02:30 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Sending a "status"
Message-Id: <46c5aa7c$0$16108$9b4e6d93@newsspool1.arcor-online.net>

Bill H wrote:
> Using $|++ I have learned that I can "flush" the print buffer to a
> browser while perl is doing things, instead of sending all the html
> when it is done. Is there any drawbacks to using this in the real
> world that any of you may have encountered?
> 
> Basically what I would be doing is sending a status to a client while
> the perl scripts are working such as (after sending the html headers
> and other stuff):
> 
> Saving your data...
> Processing your data...
> Generating completed pdf...
> Complete.
> 
> etc...
> 
> and then sending the ending html data.

There may be scenarios where this won't work as expected,
e.g. if the user's behind a proxy. Not every http proxy
forwards incomplete responses, especially in company networks
the proxy often fetches the whole response and does checks
(antivirus, buzzwords etc.) on it before serving it to the
client.

Another thing is that you have to watch your maximum script
run time settings in the server, though that's always the
point with long running scripts.

Otherwise, with pure HTML, there shouldn't be big problems
with unbuffered output.

-Chris


------------------------------

Date: Fri, 17 Aug 2007 06:38:07 -0700
From:  "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187357887.233826.60780@d55g2000hsg.googlegroups.com>

On Aug 17, 12:14 am, "Mumia W." <paduille.4061.mumia.w
+nos...@earthlink.net> wrote:

> Mod_perl is a strange environment. It's built for breath-taking
> efficiency, but it complicates programming. This wasn't a Perl leak--it
> was an effect of the additional complexity brought by mod_perl.

I really don't think I'm running mod_perl.  I asked a few times how
can I verify weather I am or not.  I would think that I'm running the
regular perl since the first line of each one of my scripts have, "#!/
usr/local/bin/perl", at the top.  I just noticed that I missed
including this line in my example.  This line is in my example on my
machine, I just missed, by mistake, pasting it to the forum.

If mod_perl insist on running in spite of this declaration, then I
don't know.  I have learned a lot from my reading of this group and
reading the recommended books and references, however, I still have
lots of gaps.  I would have never suspected that I was running
mod_perl.

> Enclosing the entire program in curly braces might also work to make
> sure that variables go out of scope properly, and I think you can
> configure mod_perl to compile programs in a much less persistent (and
> efficient) way; I think this is called PerlRun mode.

I'll study this "PerlRun" mode and the effect of using the curly
braces for the entire program. I would be more inclined to just run
perl, rather than mod_perl if I knew how to specify the difference.
I'm sure in the process of studying the reference, "PerlRun" mode
might help me to understand this better.

-- L. James

--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames



------------------------------

Date: Fri, 17 Aug 2007 06:58:04 -0700
From:  "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187359084.288826.101270@r29g2000hsg.googlegroups.com>

On Aug 16, 9:18 pm, xhos...@gmail.com wrote:

> Are you sure you are looking in the right place?
> I'd add something like this, which certainly should
> produce warnings, to your code:
>
> sub sdfsadf { my $x; sub alkj { $x }};
>
> Should produce warnings like
> Variable "$x" will not stay shared at -e line 1.
>
> If you don't see messages corresponding to that, then you may
> be looking in the wrong place.  On your original code, I found
> these warnings on $session, $name, and $count.

Yes.  I get the error you mention when adding your line to the sample
code.  But my example didn't produce errors before adding the lines.
Studying your reference to my example giving errors on your machine, I
was able to duplicate and figure out why I wasn't getting errors.
This is because there is information in the variables since having ran
the code, so I wasn't getting the uninitialized error message with
$name and $count.

A fresh load of the code from a different machine that didn't have the
any of the cookie information would initially give the warnings.  I
fixed the warnings by initializing them with a default null value as:

$name = $session->param('f_name') || "";
$count = $session->param("count") || "0";;

I would have done that for the example before posting it, since I
tried to find lines that duplicated the problem I was having, but
would otherwise be clean code.  I missed it because I was running
under the same session ID with the same persistent cookie.

I had mentioned in my description that there was no problem accessing
the session information.  The problem was in writing, or updating the
session information.  So since it was there, the variables were
initialized on my machine and didn't product those warning.

>
> Also, with your code on my system under mod_perl (I have mod_perl 1, not
> mod_perl 2) I see the non-update of the counter under the default file
> driver.

I'm not sure if my code on my machine is operating under any version
of mod_perl.  Do you get this same effect if you include a specifier
in the first line of the script, "#!/usr/local/bin/perl" or wherever
your normal perl is installed?

> Those sources make very scant reference to mod_perl.  If you are going to
> run under mod_perl, you definitely need to read up on that, as well.  The
> problems you are seeing are due to way you are using mod_perl, and
> related problems may well pop up in contexts other than CGI::Session as
> well.  Generally I just avoid mod_perl until I know for certain that
> it is necessary.

Likewise, I have not intentionally used mod_perl and don't think I
am.  Can you tell me how to insure that I am avoiding mod_perl, as you
do?

-- L. James

--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames



------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 765
**************************************


home help back first fref pref prev next nref lref last post