[29582] in Perl-Users-Digest
Perl-Users Digest, Issue: 826 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 6 14:09:50 2007
Date: Thu, 6 Sep 2007 11:09:08 -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 Thu, 6 Sep 2007 Volume: 11 Number: 826
Today's topics:
Ensuring parent/child processes <jrpfinch@gmail.com>
Re: Ensuring parent/child processes xhoster@gmail.com
Re: FAQ 1.13 Is it a Perl program or a Perl script? <brian.d.foy@gmail.com>
Re: FAQ 3.14 How can I use X or Tk with Perl? <ben@morrow.me.uk>
Re: FAQ 3.14 How can I use X or Tk with Perl? <brian.d.foy@gmail.com>
Re: How to continue process without waiting for the out <zencod@gmail.com>
Re: How to do Asynchronous I/O in win32? <ben@morrow.me.uk>
Re: Memory management and type casting in XS <anno4000@radom.zrz.tu-berlin.de>
Re: Perl - Gnuplot Interface <edgrsprj@ix.netcom.com>
Re: Perl variable to shell command...? <ben@morrow.me.uk>
Poll with clpmisc option <bik.mido@tiscalinet.it>
Re: Warning about unused lexical variables <bik.mido@tiscalinet.it>
Re: What is required for perl scripts to run correct wh <anno4000@radom.zrz.tu-berlin.de>
Re: What is required for perl scripts to run correct wh <anno4000@radom.zrz.tu-berlin.de>
Re: What is required for perl scripts to run correct wh deanjones7@gmail.com
Re: What is required for perl scripts to run correct wh deanjones7@gmail.com
Re: What is required for perl scripts to run correct wh <anno4000@radom.zrz.tu-berlin.de>
Re: What is required for perl scripts to run correct wh <anno4000@radom.zrz.tu-berlin.de>
Re: What is required for perl scripts to run correct wh <mark.clementsREMOVETHIS@wanadoo.fr>
Works in telnet but not in perl? <bill@ts1000.us>
Re: Works in telnet but not in perl? <glennj@ncf.ca>
Re: Works in telnet but not in perl? xhoster@gmail.com
Re: Works in telnet but not in perl? <bill@ts1000.us>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 06 Sep 2007 09:14:15 -0700
From: jrpfinch <jrpfinch@gmail.com>
Subject: Ensuring parent/child processes
Message-Id: <1189095255.133151.289130@50g2000hsm.googlegroups.com>
Below is a script that represents a much longer/complicated script
that takes up a large amount of memory. I understand that the
approved way of forking involves the parent process _just_ managing
the forking and having all the actual program-related stuff done by
the children.
Memory constraints mean I would like one parent and one child both to
do 'program-related stuff'. I would like to ensure that if either the
child or the parent die unexpectedly, then the other process dies
too.
I have read perlipc and would like to know what the approved way to do
this is. I am thinking two solutions - 1. have a die signal handler
kill the other process 2. use big eval blocks to trap any unexpected
errors and kill the other process.
Which is best? Is there a better way?
Cheers
Jon
#!/opt/perl5.8.8/bin/perl
#-------------------------------------------------------------------------------
# Interpreter settings
#-------------------------------------------------------------------------------
use warnings;
use strict;
$SIG{CHLD}='IGNORE';
my $gPid;
print "Parent process pid=$$\n";
unless (defined ($gPid = fork))
{
die "cannot fork: $!";
}
#-------------------------------------------------------------------------------
# Child process loops for 50 seconds
# How to ensure this stops if the parent process dies unexpectedly?
#-------------------------------------------------------------------------------
unless ($gPid)
{
print "Inside unless pid=$$, gpid=$gPid\n";
for (0..10)
{
sleep 5;
}
print "About to exit inside unless\n";
# i am the child
exit;
}
#-------------------------------------------------------------------------------
# Parent process loops for 20 seconds and then dies unexpectedly
#-------------------------------------------------------------------------------
print "After unless gpid=$gPid\n";
for (0..10)
{
sleep 2;
} # i am the parent
print "About to die after unless";
die "dying after unless";
print "About to waitpid after unless\n";
waitpid($gPid, 0);
exit;
__END__
------------------------------
Date: 06 Sep 2007 18:02:23 GMT
From: xhoster@gmail.com
Subject: Re: Ensuring parent/child processes
Message-Id: <20070906140225.130$gs@newsreader.com>
jrpfinch <jrpfinch@gmail.com> wrote:
> Below is a script that represents a much longer/complicated script
> that takes up a large amount of memory. I understand that the
> approved way of forking involves the parent process _just_ managing
> the forking and having all the actual program-related stuff done by
> the children.
I don't think Perl users usually buy into having a single approved way of
doing things. Or at least I certainly don't. How you use fork depends on
what you are using fork to accomplish.
> Memory constraints mean I would like one parent and one child both to
> do 'program-related stuff'.
There is enough here to pique my interest but not enough to know what to
suggest. Perhaps you can take advantage of Copy-on-write, where parent
and child automatically share the same memory as long as neither write to
it. Anyway, this kind of sounds like letting the tail wag the dog. Are
you sure it doesn't make more sense to diddle around with the memory
situation rather than with the forking situation? If you can have one
bloated parent and one bloated child, why not one small parent and two
bloated children? The parent could wait on any child, and then kill the
other. Or you could have a slim parent and a bloated child and a bloated
grandchild. If the grandchild dies unexpectedly, the middle one will get a
SIG{CHLD} and can kill itself. If the middle one dies unexpected, the
super-parent will get a SIG{CHLD} (or just return from a blocking waitpid)
and can then kill the whole process group.
> I would like to ensure that if either the
> child or the parent die unexpectedly, then the other process dies
> too.
>
> I have read perlipc and would like to know what the approved way to do
> this is. I am thinking two solutions - 1. have a die signal handler
> kill the other process 2. use big eval blocks to trap any unexpected
> errors and kill the other process.
That would work if your "unexpected" errors happen only in expected ways.
What if you get blown out of the water by an untrapped or untrappable
signal? Neither signal handlers nor eval blocks can then kill off the
partner. Is that tolerable or not?
If you have to detect even truly unexpected deaths, then one way would
be to open a pipe between parent and child, and never close or write to the
pipe. If the pipe becomes readable (as detected by select or IO::Select)
then the other party must have gone away. Alas this requires polling on
the part of the survivor.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 06 Sep 2007 11:10:22 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 1.13 Is it a Perl program or a Perl script?
Message-Id: <060920071110221052%brian.d.foy@gmail.com>
In article <5k91caF2lpqaU1@mid.dfncis.de>, Anno Siegel
<anno4000@radom.zrz.tu-berlin.de> wrote:
> On 2007-09-05 21:55:04 +0200, Aaron Sherman <AaronJSherman@gmail.com> said:
> In this terminology, a Perl program would clearly be a script, never mind
> Perl 5 or 6. That the term is occasionally used with disparaging intent
> shouldn't stop us from using it in useful ways.
Indeed. I don't think most people even care. The very few that do have
other problems with Perl that a change of semantics isn't going to
change. :)
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 6 Sep 2007 15:44:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: FAQ 3.14 How can I use X or Tk with Perl?
Message-Id: <oag5r4-7m1.ln1@osiris.mauzo.dyndns.org>
Quoth PerlFAQ Server <brian@stonehenge.com>:
>
> 3.14: How can I use X or Tk with Perl?
I've had it in mind for a while that this FAQ entry is really very
dated. What do people think of this update: have I missed anything
important?
Ben
=head2 How can I write a GUI (X, Tk, Gtk, etc.) in Perl?
There are a number of modules which let you write GUIs in Perl. Most
GUI toolkits have a perl interface: an incomplete list follows.
=over 4
=item Tk
This works under Unix and Windows, and the current version doesn't
look half as bad under Windows as it used to. Some of the gui elements
still don't 'feel' quite right, though. The interface is very natural
and 'perlish', making it easy to use in small scripts that just need a
simple gui. It hasn't been updated in a while.
=item Wx
This is a Perl binding for the cross-platform wxWidgets toolkit
L<http://www.wxwidgets.org>. It works under Unix, Win32 and Mac OS X,
using native widgets (Gtk under Unix). The interface follows the C++
interface closely, but the documentation is a little sparse for someone
who doesn't know the library, mostly just referring you to the C++
documentation.
=item Gtk and Gtk2
These are Perl bindings for the Gtk toolkit L<http://www.gtk.org>. The
interface changed significantly between versions 1 and 2 so they have
separate Perl modules. It runs under Unix, Win32 and Mac OS X (currently
it requires an X server on Mac OS, but a 'native' port is underway), and
the widgets look the same on every plaform: i.e., they don't match the
native widgets. As with Wx, the Perl bindings follow the C API closely,
and the documentation requires you to read the C documentation to
understand it.
=item Win32::GUI
This provides access to most of the Win32 GUI widgets from Perl.
Obviously, it only runs under Win32, and uses native widgets. The Perl
interface doesn't really follow the C interface: it's been made more
Perlish, and the documentation is pretty good. More advanced stuff may
require familiarity with the C Win32 APIs, or reference to MSDN.
=item CamelBones
CamelBones L<http://camelbones.sourceforge.net> is a Perl interface to
Mac OS X's Cocoa GUI toolkit, and as such can be used to produce native
GUIs on Mac OS X. It's not on CPAN, as it requires frameworks that
CPAN.pm doesn't know how to install, but installation is via the
standard OSX package installer. The Perl API is, again, very close to
the ObjC API it's wrapping, and the documentation just tells you how to
translate from one to the other.
=item Qt
There is a Perl interface to TrollTech's Qt toolkit, but it does not
appear to be maintained.
=item Athena
Sx is an interface to the Athena widget set which comes with X, but
again it appears not to be much used nowadays.
=back
------------------------------
Date: Thu, 06 Sep 2007 11:18:57 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 3.14 How can I use X or Tk with Perl?
Message-Id: <060920071118571937%brian.d.foy@gmail.com>
In article <oag5r4-7m1.ln1@osiris.mauzo.dyndns.org>, Ben Morrow
<ben@morrow.me.uk> wrote:
> Quoth PerlFAQ Server <brian@stonehenge.com>:
> >
> > 3.14: How can I use X or Tk with Perl?
>
> I've had it in mind for a while that this FAQ entry is really very
> dated. What do people think of this update: have I missed anything
> important?
Excellent. I've updated perlfaq3.pod.
If anyone has any updates, please reply to this thread or post to
perlfaq-workers AT perl org.
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Thu, 06 Sep 2007 09:12:25 -0700
From: Cod <zencod@gmail.com>
Subject: Re: How to continue process without waiting for the output of system()?
Message-Id: <1189095145.269022.280670@50g2000hsm.googlegroups.com>
On 9 2 , 8 59 , "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> Cod <zen...@gmail.com> wrote in news:1188570633.227615.319150
> @l22g2000prc.googlegroups.com:
>
>
>
>
>
> > Thank you all.
>
> > Use Narthring's method or xhos's method, there is one problem: BEFORE
> > the calc closed, the programe won't exit. Just like this:
>
> > d:\>perl -e "fork or do {system('calc'); exi
> > t}; $|=1; print 'hello' "
> > hello
>
> > AFTER calc closed, below appears:
> > d:\>
>
> > By Follow Ben Morrow say, I tried:
> > d:\>perl -e "fork or do {system('calc'); exi
> > t}; $|=1; print 'hello' "
> > hello
> > d:\>
>
> > This time it works just what I wanted.
>
> If you want more control, you can use Win32::Process
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use FindBin qw( $Bin );
>
> use Win32::Process;
> use Win32;
>
> sub ErrorMsg { Win32::FormatMessage( Win32::GetLastError() ) }
>
> my $calc_path = q{C:/WINDOWS/system32/calc.exe};
>
> my $calc_process;
>
> Win32::Process::Create(
> $calc_process,
> $calc_path,
> 'calc',
> 0,
> NORMAL_PRIORITY_CLASS,
> $Bin
> ) or die sprintf "Error starting '%s': %s", $calc_path, ErrorMsg();
>
> sleep 3;
>
> $calc_process->Suspend();
>
> sleep 3;
>
> $calc_process->Resume();
>
> sleep 10;
>
> $calc_process->Kill(0);
>
> __END__
>
> Sinan
> --
> A. Sinan Unur <1...@llenroc.ude.invalid>
> (remove .invalid and reverse each component for email address)
> clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>- -
>
> - -
thx, I've tried Win32::Process, It's very useful , although need more
typing:)
------------------------------
Date: Thu, 6 Sep 2007 14:56:28 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to do Asynchronous I/O in win32?
Message-Id: <chd5r4-af1.ln1@osiris.mauzo.dyndns.org>
Quoth "sonet" <sonet.all@gmail.com>:
> Have any modules like http://www.summerblue.net/computing/libiocp/index.html
> for win32-perl ?
If you want to use real Win32 overlapped IO, you can use the functions
in Win32API::File. You will need to closely refer to the MSDN
documentation for these, though: the interface is currently not very
friendly, and you will need to build your own OVERLAPPED structure using
pack.
I was about to suggest using POE, as that is the standard suggestion for
event loops, but it appears not to support operations on ordinary files
under Win32 (due to select(2) being deeply broken). If you only want to
monitor sockets, you should be able to use any of the select-based
systems: POE has its own, or you can use Event.pm.
If you are a C programmer, and you like the libiocp interface, you could
try your hand at wrapping it in an XS module. It doesn't look too hard:
you would need to write your own set of C callbacks to register, and
then have those callbacks call the Perl callbacks (if that makes sense
:) ). Start by reading perlxs, and you'll probably need to follow that
with perlcall. Or you could use Inline::C, though given that you'd still
have to have C-callbacks-calling-Perl-callbacks I doubt it would be much
easier.
Good luck: this is clearly an area where Perl's Win32 support needs
work, so I hope you can find something that does what you need.
Ben
------------------------------
Date: Thu, 6 Sep 2007 17:04:22 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: Memory management and type casting in XS
Message-Id: <5kaj7mF2s68sU1@mid.dfncis.de>
On 2007-09-06 10:46:45 +0200, Ye Wenbin <wenbinye@gmail.com> said:
> Hi,
> I am going to write a XS binding for an C library. I have some
> question about the memory management and type casting. For example,
> the library contain a string and list module. I bind DESTROY to
> str_del function which free the string struct, that is ok when using
> the string module alone. But if with list, there comes the problem. If
> I use list_get to fetch a element from the list which is a string and
> the result is a perl object in a scalar. When the object go out of the
> scope, it will invoke DESTROY function. But the list still has the
> pointer to the string. Because the string module don't have reference
> count, so it is not posible to decide whether free the object or not
> in DESTROY function. So how to deal with this situation?
Make copies that can be dealt with by perl's garbage collection.
In general that's the only safe way to return data from an external
library to perl space.
[...]
Anno
------------------------------
Date: Thu, 6 Sep 2007 06:38:14 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Perl - Gnuplot Interface
Message-Id: <13dvpljom7ur2d1@corp.supernews.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:13du27dtkchf788@corp.supernews.com...
> PERL - GNUPLOT INTERFACE
Thanks to one and all for the responses.
Having considered the available information I am presently planning to go
with Perl (or Basic or Fortran etc. for other people) and Gnuplot. One of
the main reasons for choosing Gnuplot rather than one of the Perl chart
routines is because certain of the planned applications could be run
entirely with a standalone Gnuplot program plus a data file. In those cases
a separate programming language such as Perl would not be needed. The
following is one example:
Wave Charts
http://www.freewebz.com/eq-forecasting/130.html
For thousands of years people have been wondering why earthquakes occur at
the times when they occur. Various theories have proposed that earthquake
triggering times are linked with the gravitational pulls of the sun or the
moon, ocean tides etc. What I did was generate data for a number of those
variables and plotted them on the same time axis chart (Wave Chart). Using
the charts researchers can draw vertical lines on the days when earthquakes
of interest occurred and see which one of those variables might have been
involved with the triggering process.
The data file for the main Wave Chart is a number array with about 20
columns and 7500 rows. Presently a spreadsheet is used to generate the Wave
Charts. But Gnuplot should be able to manage that. Researchers around the
world would like to have such a program right now.
For future questions related specifically to Gnuplot I will probably just
post to that newsgroup. But since I am already posting this report I have
two Gnuplot questions.
1. If you have a number array that has 100 rows and 100 columns and you
wish to display only a 10 x 10 element subset at a time:
A. Should you plot all 100 x 100 elements and then try to scroll left and
right and up and down to see the area of interest?
B. Of, should you tell Gnuplot to plot the particular 10 x 10 element
subset of choice and change the starting row and column and replot the data
in order to scroll left and right and up and down?
Looking at the Gnuplot demos I formed the impression that B has to be used.
Choice A is not allowed.
2. Are there any already existing Gnuplot programs that use "bound" keys
such as RIGHT ARROW etc. and which allow you to work with large number
arrays and use data subsets to scroll left and right, up and down, zoom in
and out etc.?
I took another look at the Gnuplot Web site for information regarding
Question 2 but did not see much along those lines.
Comment - After running through the Gnuplot demos I have to say that the
plotting ability and speed of the program are impressive! And the program
itself does not appear to require too much RAM memory.
------------------------------
Date: Thu, 6 Sep 2007 15:06:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl variable to shell command...?
Message-Id: <u4e5r4-af1.ln1@osiris.mauzo.dyndns.org>
Quoth Josef Moellers <josef.moellers@fujitsu-siemens.com>:
> Benoit Lefebvre wrote:
> > On Sep 4, 5:55 pm, Rohit <rohit.makas...@gmail.com> wrote:
> >
> >>$filename=myFile.txt
> >>
> >>@fileRec=`cat $filename`;
> >>
> >>Here shell is not able to identify $filename variable. Any idea or
> >>suggestions?
> >
> > I like to do it that way
> >
> > $filename = "myfile.txt";
> >
> > $cmd = "cat ". $filename;
> >
> > @fileRec = `$cmd`;
>
> While this is how I'd do it, too (I can then show the entire command for
> debugging purposes),
For cases when you need an external command, I'd agree. This is not one
of them: perl is perfectly capable of reading a file on its own:
my @fileRec = do {
open my $FH, '<', 'myFile.txt'
or die "can't read 'myFile.txt': $!";
<$FH>;
};
or indeed
use File::Slurp qw/read_file/;
my @fileRec = read_file 'myFile.txt';
> Most likeley, the file isn't accessable, e.g. because it's in a
> different path or it is read-protected, or the OP isn't telling us
> everything, as his code is not valid Perl anyway.
...except it is, it just doesn't mean what he thinks it does:
~% perl -le'print myFile.txt'
myFiletxt
~%
'myFile' and 'txt' are autoquoted, and the . concatenates them. Yet
another reason why you should always use strictures: in this case, the
rather perversely-named strict 'subs' (it should clearly be strict
'strings') rather than the usual strict 'vars'.
Ben
------------------------------
Date: Thu, 06 Sep 2007 14:31:38 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Poll with clpmisc option
Message-Id: <4ksvd359ddl6hdd9acm3tc0cp747ogu5p0@4ax.com>
http://perlmonks.org/?node_id=637052
When I'm arguing with a fool...
* chances are he's doing the same => 44/33%
* certainly he's doing the same => 29/22%
* I'm in clpmisc, being told I am an elitist b**tard for pointing out
that "it doesn't work" is not an appropriate description of the
problem => 10/7%
* he's claiming Perl to be "constantly loosing ground on php" =>
20/15%
* UR HLP CAN HAS BEEN SQL IS TOO MUCH DOCS PLZ SUPER URGENT THX. =>
31/23%
(Results thus far)
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 06 Sep 2007 19:33:30 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Warning about unused lexical variables
Message-Id: <u9e0e3t71td0jp1r5b1tlj98et7ihlo56h@4ax.com>
On Wed, 05 Sep 2007 18:53:28 +0200, Michele Dondi
<bik.mido@tiscalinet.it> wrote:
>Here is what has been said:
Update:
Re: Warning about unused lexical variables
by bduggan on Sep 06, 2007 at 19:06 GMT-2
I was looking for this recently, and found it mentioned in
Perl::Critic::TODO (TBD::VariableNotUsed).
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 6 Sep 2007 16:31:36 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <5kaha7F2rl0cU1@mid.dfncis.de>
On 2007-09-06 14:13:25 +0200, Mark Clements
<mark.clementsREMOVETHIS@wanadoo.fr> said:
> deanjones7@gmail.com wrote:
>> Anno Siegel wrote:
>>> On 2007-09-06 10:17:09 +0200, usenet@DavidFilmer.com said:
>>>
>>>> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
>>>>> the perl script fails without any errors when the system is booted.
>>>> That means NOTHING. How do you know it fails? How do you even know
>>>> it runs? Why would you think it should run on a reboot?
>>> Well, the subject mentions "... launched from rc scripts" which I take
>>> to mean it is called from one of the /etc/*.rc scripts (or however these
>>> are organized in HPUX).
>>
>> That's correct. There's a start/stop script in /sbin/init.d with the
>> usual links to the rc? directories. That script works correctly when
>> run interactively.
>
> Add some logging to the script? I'd use Log::Log4perl or one of the
> syslog alternatives.
Logging is a good idea, but syslog assumes that syslogd is already running
when the script starts. During startup there is no guarantee for that.
To be sure, create a logfile in the / file system (the only one that can
be relied on to be mounted), and print() log messages to that file directly.
Anno
------------------------------
Date: Thu, 6 Sep 2007 13:54:25 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <5ka83hF2npdtU1@mid.dfncis.de>
On 2007-09-06 10:17:09 +0200, usenet@DavidFilmer.com said:
> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
>> the perl script fails without any errors when the system is booted.
>
> That means NOTHING. How do you know it fails? How do you even know
> it runs? Why would you think it should run on a reboot?
Well, the subject mentions "... launched from rc scripts" which I take
to mean it is called from one of the /etc/*.rc scripts (or however these
are organized in HPUX). These scripts run at boot time to set up the
system and thus run at a time when the system is not yet completely set
up. Lots of things can go wrong if something is called too early in the
process.
Anno
------------------------------
Date: Thu, 06 Sep 2007 11:59:58 -0000
From: deanjones7@gmail.com
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <1189079998.583424.314420@w3g2000hsg.googlegroups.com>
use...@DavidFilmer.com wrote:
> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
> > the perl script fails without any errors when the system is booted.
>
> That means NOTHING. How do you know it fails?
Because if it was running I would see it with "ps -ef" and it would be
reporting errors as they come through the pipe.
> How do you even know it runs?
> Why would you think it should run on a reboot?
Which part of my original post didn't you comprehend?
> With no code and a meaningless description of the problem I doubt
> anyone is psychic enough to advise you of what your actual problem is.
That's fine. I was hoping for some obvious finger pointing before I
delve into more advanced diagnostics.
------------------------------
Date: Thu, 06 Sep 2007 12:05:18 -0000
From: deanjones7@gmail.com
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <1189080318.638380.14450@50g2000hsm.googlegroups.com>
Anno Siegel wrote:
> On 2007-09-06 10:17:09 +0200, usenet@DavidFilmer.com said:
>
> > On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
> >> the perl script fails without any errors when the system is booted.
> >
> > That means NOTHING. How do you know it fails? How do you even know
> > it runs? Why would you think it should run on a reboot?
>
> Well, the subject mentions "... launched from rc scripts" which I take
> to mean it is called from one of the /etc/*.rc scripts (or however these
> are organized in HPUX).
That's correct. There's a start/stop script in /sbin/init.d with the
usual links to the rc? directories. That script works correctly when
run interactively.
> These scripts run at boot time to set up the
> system and thus run at a time when the system is not yet completely set
> up. Lots of things can go wrong if something is called too early in the
> process.
The funny thing is I have another perl script that runs fine when run
at boot. The only difference is that its not listening on a pipe like
the problematic one is.
I wonder if its how I use STDIN. In the problematic script I just do -
while (<>)
{
...
}
to read input from the pipe. Should I be using STDIN explicitly
instead?
------------------------------
Date: Thu, 6 Sep 2007 16:23:28 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <5kagqvF2jljaU1@mid.dfncis.de>
On 2007-09-06 14:05:18 +0200, deanjones7@gmail.com said:
> Anno Siegel wrote:
>> On 2007-09-06 10:17:09 +0200, usenet@DavidFilmer.com said:
>>
>>> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
>>>> the perl script fails without any errors when the system is booted.
>>>
>>> That means NOTHING. How do you know it fails? How do you even know
>>> it runs? Why would you think it should run on a reboot?
>>
>> Well, the subject mentions "... launched from rc scripts" which I take
>> to mean it is called from one of the /etc/*.rc scripts (or however these
>> are organized in HPUX).
>
> That's correct. There's a start/stop script in /sbin/init.d with the
> usual links to the rc? directories.
It would have been a good idea to mention that explicitly in the body of
your posting. "Launched from rc" is not part of any standard terminology.
> That script works correctly when
> run interactively.
>
>> These scripts run at boot time to set up the
>> system and thus run at a time when the system is not yet completely set
>> up. Lots of things can go wrong if something is called too early in the
>> process.
>
> The funny thing is I have another perl script that runs fine when run
> at boot.
The behavior depends heavily on *when* the script is run during the
startup process. "Run at boot" is much too unspecific.
> The only difference is that its not listening on a pipe like
> the problematic one is.
The Perl scripts aren't identical, are they? I bet the pipe isn't the
only difference. In fact, pipe behavior sounds like a rather unlikely
candidate.
> I wonder if its how I use STDIN. In the problematic script I just do -
>
> while (<>)
> {
> ...
> }
>
> to read input from the pipe. Should I be using STDIN explicitly
> instead?
I have no idea. Post the code of the script, the actual call, and
describe in what stage of startup the call happens. Is perl even
part of the HPUX 11 distribution? Are all modules your script may
be using?
In fact, you might be better off asking in a HPUX-oriented newsgroup.
The problem may not be specific to perl at all.
Anno
------------------------------
Date: Thu, 6 Sep 2007 16:51:09 +0200
From: Anno Siegel <anno4000@radom.zrz.tu-berlin.de>
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <5kaietF2r7ojU1@mid.dfncis.de>
On 2007-09-06 13:59:58 +0200, deanjones7@gmail.com said:
> use...@DavidFilmer.com wrote:
>> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
>>> the perl script fails without any errors when the system is booted.
>>
>> That means NOTHING. How do you know it fails?
>
> Because if it was running I would see it with "ps -ef"
Would you? How long does that thing run? Do you even have
an interactive process to run ps from when the script is
supposed to be starting?
> and it would be
> reporting errors as they come through the pipe.
Reporting to where? And what errors? Last thing you were in doubt
if the pipe even works. How can you rely on it to show if the script
is started?
>> How do you even know it runs?
>> Why would you think it should run on a reboot?
>
> Which part of my original post didn't you comprehend?
Probably the obscure "launched from rc" part you hid in an
overlong subject line. Essential information belongs in the
body of a posting. This is a Perl group, not a Unix goup.
Some posters may never have seen an rc* file in their lives.
>> With no code and a meaningless description of the problem I doubt
>> anyone is psychic enough to advise you of what your actual problem is.
>
> That's fine. I was hoping for some obvious finger pointing before I
> delve into more advanced diagnostics.
Then you were posting to the wrong newsgroup. The situation during
startup is system-specific, not language-specific.
Anno
------------------------------
Date: Thu, 06 Sep 2007 14:13:25 +0200
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: What is required for perl scripts to run correct when launched from rc scripts on HPUX 11?
Message-Id: <46dfeee5$0$5101$ba4acef3@news.orange.fr>
deanjones7@gmail.com wrote:
> Anno Siegel wrote:
>> On 2007-09-06 10:17:09 +0200, usenet@DavidFilmer.com said:
>>
>>> On Sep 6, 1:06 am, deanjon...@gmail.com wrote:
>>>> the perl script fails without any errors when the system is booted.
>>> That means NOTHING. How do you know it fails? How do you even know
>>> it runs? Why would you think it should run on a reboot?
>> Well, the subject mentions "... launched from rc scripts" which I take
>> to mean it is called from one of the /etc/*.rc scripts (or however these
>> are organized in HPUX).
>
> That's correct. There's a start/stop script in /sbin/init.d with the
> usual links to the rc? directories. That script works correctly when
> run interactively.
Add some logging to the script? I'd use Log::Log4perl or one of the
syslog alternatives.
$logger->info("starting up");
...
$logger->debug("processing line number $count");
$logger->info("exiting normally");
...
and
(assuming you've wrapped the main body of the program in eval {} )
$logger->error("exiting abnormally with error=$@");
Mark
------------------------------
Date: Thu, 06 Sep 2007 09:48:43 -0700
From: Bill H <bill@ts1000.us>
Subject: Works in telnet but not in perl?
Message-Id: <1189097323.352474.129170@50g2000hsm.googlegroups.com>
I have a perl program that is converting a pdf file to a jpg using
imagemagik and gs. Using the following command line in a telnet shell
logged in as the webmaster and in the same directory as the perl
program it works:
cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
resize 300 ZGRH3122CHAP070827063618-1-1.jpg
But when I do it in perl with the following:
system("cd $displaypath;/usr/local/bin/convert $THISPROJECT
$thepagemap[$i].pdf -resize 300 $THISPROJECT$thepagemap[$i].jpg");
which expands out to (same as above):
cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
resize 300 ZGRH3122CHAP070827063618-1-1.jpg
I get this error:
sh: gs: command not found
convert: Postscript delegate failed
`ZGRH3122CHAP070827063618-1-1.pdf'.
convert: missing an image filename `ZGRH3122CHAP070827063618-1-1.jpg'.
Anyone have any clue why I would get this error? Convert works fine,
it just doesn't work with gs (ghostscript) when I call it from the
perl. Also gs is in /usr/local/bin same as convert.
Bill H
------------------------------
Date: 6 Sep 2007 17:11:27 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: Works in telnet but not in perl?
Message-Id: <slrnfe0d5v.egu.glennj@smeagol.ncf.ca>
At 2007-09-06 12:48PM, "Bill H" wrote:
[...]
> I get this error:
>
> sh: gs: command not found
> convert: Postscript delegate failed
> `ZGRH3122CHAP070827063618-1-1.pdf'.
> convert: missing an image filename `ZGRH3122CHAP070827063618-1-1.jpg'.
>
> Anyone have any clue why I would get this error? Convert works fine,
> it just doesn't work with gs (ghostscript) when I call it from the
> perl. Also gs is in /usr/local/bin same as convert.
What's $ENV{PATH} ? What other environment differences exist?
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
------------------------------
Date: 06 Sep 2007 17:33:45 GMT
From: xhoster@gmail.com
Subject: Re: Works in telnet but not in perl?
Message-Id: <20070906133347.743$5v@newsreader.com>
Bill H <bill@ts1000.us> wrote:
> I have a perl program that is converting a pdf file to a jpg using
> imagemagik and gs. Using the following command line in a telnet shell
> logged in as the webmaster and in the same directory as the perl
> program it works:
>
> cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
> resize 300 ZGRH3122CHAP070827063618-1-1.jpg
>
> But when I do it in perl with the following:
>
> system("cd $displaypath;/usr/local/bin/convert $THISPROJECT
> $thepagemap[$i].pdf -resize 300 $THISPROJECT$thepagemap[$i].jpg");
>
> which expands out to (same as above):
>
> cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
> resize 300 ZGRH3122CHAP070827063618-1-1.jpg
>
> I get this error:
>
> sh: gs: command not found
> convert: Postscript delegate failed
> `ZGRH3122CHAP070827063618-1-1.pdf'.
> convert: missing an image filename `ZGRH3122CHAP070827063618-1-1.jpg'.
>
> Anyone have any clue why I would get this error? Convert works fine,
> it just doesn't work with gs (ghostscript) when I call it from the
> perl. Also gs is in /usr/local/bin same as convert.
It looks to me like /usr/local/bin/convert doesn't use a fully resolved
path to get to gs, but rather depends on gs being the in the search path.
So if you set $ENV{PATH} to include /usr/local/bin/ before calling
/usr/local/bin/convert, it should work. Or you could change convert so
it doesn't rely on search paths to find gs.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 06 Sep 2007 10:46:26 -0700
From: Bill H <bill@ts1000.us>
Subject: Re: Works in telnet but not in perl?
Message-Id: <1189100786.411165.123780@19g2000hsx.googlegroups.com>
On Sep 6, 1:33 pm, xhos...@gmail.com wrote:
> Bill H <b...@ts1000.us> wrote:
> > I have a perl program that is converting a pdf file to a jpg using
> > imagemagik and gs. Using the following command line in a telnet shell
> > logged in as the webmaster and in the same directory as the perl
> > program it works:
>
> > cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
> > resize 300 ZGRH3122CHAP070827063618-1-1.jpg
>
> > But when I do it in perl with the following:
>
> > system("cd $displaypath;/usr/local/bin/convert $THISPROJECT
> > $thepagemap[$i].pdf -resize 300 $THISPROJECT$thepagemap[$i].jpg");
>
> > which expands out to (same as above):
>
> > cd Pages;/usr/local/bin/convert ZGRH3122CHAP070827063618-1-1.pdf -
> > resize 300 ZGRH3122CHAP070827063618-1-1.jpg
>
> > I get this error:
>
> > sh: gs: command not found
> > convert: Postscript delegate failed
> > `ZGRH3122CHAP070827063618-1-1.pdf'.
> > convert: missing an image filename `ZGRH3122CHAP070827063618-1-1.jpg'.
>
> > Anyone have any clue why I would get this error? Convert works fine,
> > it just doesn't work with gs (ghostscript) when I call it from the
> > perl. Also gs is in /usr/local/bin same as convert.
>
> It looks to me like /usr/local/bin/convert doesn't use a fully resolved
> path to get to gs, but rather depends on gs being the in the search path.
> So if you set $ENV{PATH} to include /usr/local/bin/ before calling
> /usr/local/bin/convert, it should work. Or you could change convert so
> it doesn't rely on search paths to find gs.
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> Usenet Newsgroup Service $9.95/Month 30GB- Hide quoted text -
>
> - Show quoted text -
That was recommended by the admin at imagemagick also, he also told me
the easier method of just modifying the config file (not mentioned in
the docs that i could find), so it works great now!
Bill H
------------------------------
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 826
**************************************
