[30882] in Perl-Users-Digest
Perl-Users Digest, Issue: 2127 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 14 21:14:34 2009
Date: Wed, 14 Jan 2009 18:14:27 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 14 Jan 2009 Volume: 11 Number: 2127
Today's topics:
Re: unable to open file <"kteague at pobox dot com">
Re: unable to open file <tim@burlyhost.com>
Re: unable to open file <jurgenex@hotmail.com>
Re: unable to open file <"kteague at pobox dot com">
Re: unable to open file <tim@burlyhost.com>
Re: unable to open file <tadmc@seesig.invalid>
Re: unable to open file <tadmc@seesig.invalid>
Re: unable to open file <tim@burlyhost.com>
Re: unable to open file <tadmc@seesig.invalid>
Re: unable to open file <Tintin@teranews.com>
Re: unable to open file <Tintin@teranews.com>
Re: unable to open file <jurgenex@hotmail.com>
Re: unable to open file <jurgenex@hotmail.com>
Re: unable to open file <tadmc@seesig.invalid>
Re: Using exec() <bill@ts1000.us>
Re: Using exec() (Tim McDaniel)
Re: Using exec() <jurgenex@hotmail.com>
Re: Using exec() <tadmc@seesig.invalid>
Re: Using exec() xhoster@gmail.com
Re: Using exec() <tim@burlyhost.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Jan 2009 13:21:54 -0800
From: Ken Teague <"kteague at pobox dot com">
Subject: Re: unable to open file
Message-Id: <kuudnS7rP5zmyvPUnZ2dnUVZ_judnZ2d@giganews.com>
Tad J McClellan wrote:
>> Is there
>> a way I could avoid absolute paths? I tend to think they're evil in
>> source.
>
>
> It appears that your program has some other current working directory.
>
> You need to find out what it is, or chdir() to a known location if
> relative paths are to work.
Thank you all for your assistance. I've circumvented the problem by adding the following to line 11 of the perl script:
chdir('E:\\0\\0\\25\\44\\188533\\user\\191178\\htdocs\\') or die ("Cannot cd to new directory: $!\n");
I'm not keen on this circumvention because of using an absolute file system path. If this is the only way to resolve the issue, I guess I'll have to stick with it. If there's a way to use relative pathing, I'd like to know how. Thanks!
- Ken
------------------------------
Date: Wed, 14 Jan 2009 13:34:31 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: unable to open file
Message-Id: <HTsbl.21818$H12.10271@newsfe12.iad>
Ken Teague <"kteague at pobox dot com"> wrote:
> Tad J McClellan wrote:
>>> Is there
>>> a way I could avoid absolute paths? I tend to think they're evil in
>>> source.
>>
>>
>> It appears that your program has some other current working
>> directory.
>>
>> You need to find out what it is, or chdir() to a known location if
>> relative paths are to work.
>
> Thank you all for your assistance. I've circumvented the problem by
> adding the following to line 11 of the perl script:
>
> chdir('E:\\0\\0\\25\\44\\188533\\user\\191178\\htdocs\\') or die
> ("Cannot cd to new directory: $!\n");
>
> I'm not keen on this circumvention because of using an absolute file
> system path. If this is the only way to resolve the issue, I guess
> I'll have to stick with it. If there's a way to use relative pathing,
> I'd like to know how. Thanks!
>
> - Ken
Shouldn't you be able to use / on Windows, rather than escaping each \
with \\? I thought you could? I've not used Windows for a decade, so
I don't recall, but I think you can use /? Anyway, for using the
relative path, it's difficult to say, we'd need to know the path of the
file/directory "relative" to the script. What's the absolute path
you're accessing this from and to? Which is the above; from, or to?
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 14:10:41 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <gjosm456ic5jk4e7l2s6g3l0v0h6mo7n82@4ax.com>
Ken Teague <"kteague at pobox dot com"> wrote:
>I'm not keen on this circumvention because of using an absolute file system path. If this is the only way to resolve the issue, I guess I'll have to stick with it. If there's a way to use relative pathing, I'd like to know how. Thanks!
[Please use line breaks at about 75 character as has been customary for
the past 2 decades]
Easy enough to do. Find out your CWD (current working directory) and
then use a relative path from that location.
jue
------------------------------
Date: Wed, 14 Jan 2009 14:23:13 -0800
From: Ken Teague <"kteague at pobox dot com">
Subject: Re: unable to open file
Message-Id: <6-ednWaNUNFE-PPUnZ2dnUVZ_oydnZ2d@giganews.com>
Tim Greer wrote:
>> Thank you all for your assistance. I've circumvented the problem by
>> adding the following to line 11 of the perl script:
>>
>> chdir('E:\\0\\0\\25\\44\\188533\\user\\191178\\htdocs\\') or die
>> ("Cannot cd to new directory: $!\n");
>>
>> I'm not keen on this circumvention because of using an absolute file
>> system path. If this is the only way to resolve the issue, I guess
>> I'll have to stick with it. If there's a way to use relative pathing,
>> I'd like to know how. Thanks!
>>
>> - Ken
>
> Shouldn't you be able to use / on Windows, rather than escaping each \
> with \\? I thought you could? I've not used Windows for a decade, so
> I don't recall, but I think you can use /?
VI looks at using / as the delimiter as syntactically correct. I've
implemented this change and it seems to work fine. Thanks for that info.
> Anyway, for using the relative path, it's difficult to say, we'd need
> to know the path of the file/directory "relative" to the script.
> What's the absolute path you're accessing this from and to? Which
> is the above; from, or to?
Since this is a hosted server and I only have FTP access, I was able to
determine it's running ActiveState perl v5.8.7. In my experience (and
if memory serves me right), this is installed under:
C:\Program Files\ActiveState\perl\bin
Since this box is hosted and I only have FTP access, I don't have the
ability to set environment variables. It's also a Windows box, so I
don't think I can execute shell commands with backticks.
The web root is:
E:\0\0\25\44\188533\user\191178\htdocs
... and there's a cgi-bin directory underneath it:
E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
The perl script resides in:
E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin contains the following:
csvsearch.pl
prodscript.html
products.txt
csvsearch.pl is, of course, the perl script we're dealing with.
prodscript.html is the web page that csvsearch.pl gives its data to and
is the "search results" page. products.txt is a simple text file
containing product IDs and description in this format:
productID|description|productID.pdf
... for example:
227229|PRETREATMENT CARPET 28H 34858 3M TWIST'N 62L|227229.pdf
350111|POLISH SS AERO 14002 3M 1221oz|350111.pdf
- Ken
------------------------------
Date: Wed, 14 Jan 2009 14:35:01 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: unable to open file
Message-Id: <qMtbl.51593$3_4.17632@newsfe10.iad>
Ken Teague <"kteague at pobox dot com"> wrote:
> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin contains the following:
> csvsearch.pl
> prodscript.html
> products.txt
You shouldn't need to worry about the path to Perl on a Windows system
in most situations (especially via CGI -- it should automatically know
by the file extension).
As for the files you're using (the script you're running and the file
you're opening), if they are all in the same directory, you should be
able to just use "./file" as the path to the file you're trying to open
or just "file", so either I've misunderstood the overall problem or
wasn't noticing the difference in paths you're trying to use.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 16:25:47 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmspjb.6un.tadmc@tadmc30.sbcglobal.net>
Tim Greer <tim@burlyhost.com> wrote:
> for using the
> relative path, it's difficult to say, we'd need to know the path of the
> file/directory "relative" to the script.
^^^^^^^^^^^^^^^^^^^^^^^
No we don't.
We need to know the path of the file/directory relative to the cwd.
The cwd does not need to be the same as the script's directory,
though most web servers are configured to make that so.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 16:23:34 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmspf6.6un.tadmc@tadmc30.sbcglobal.net>
Ken Teague <"kteague at pobox dot com"> wrote:
> Tad J McClellan wrote:
[ There's a missing attribution here... ]
>>> Is there
>>> a way I could avoid absolute paths?
Yes.
Configure your new web server the way the old one was configured
(with the cwd set to the cgi-bin/ or whatever).
> chdir('E:\\0\\0\\25\\44\\188533\\user\\191178\\htdocs\\')
Gak! What's with all the doubled backslashes?
You only need one of them.
(Actually you don't need any if you leave the last one off.)
Try this:
---------------------------
#!/usr/bin/perl
use warnings;
use strict;
print 'E:\\0\\0\\25\\44\\188533\\user\\191178\\htdocs\\', "\n";
print 'E:\0\0\25\44\188533\user\191178\htdocs\\', "\n";
---------------------------
Even better, use sane slashes instead (yes, they work on M$):
chdir('E:/0/0/25/44/188533/user/191178/htdocs')
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 16:12:37 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: unable to open file
Message-Id: <Vbvbl.34854$Nv1.14774@newsfe03.iad>
Tad J McClellan wrote:
> Tim Greer <tim@burlyhost.com> wrote:
>
>> for using the
>> relative path, it's difficult to say, we'd need to know the path of
>> the file/directory "relative" to the script.
> ^^^^^^^^^^^^^^^^^^^^^^^
>
> No we don't.
>
> We need to know the path of the file/directory relative to the cwd.
>
> The cwd does not need to be the same as the script's directory,
> though most web servers are configured to make that so.
>
>
Of course not, but the OP didn't know how to tell (which is why they
asked), so just knowing the directory the script is in (that the script
outputs), doesn't help to give the OP a definitive answer, unless the
OP knows the actual path the file resides in that they want to read.
That could be any path. And, of course the cwd doesn't need to be in
the same directory as the script.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
Date: Wed, 14 Jan 2009 18:00:54 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmsv5m.8h8.tadmc@tadmc30.sbcglobal.net>
Ken Teague <"kteague at pobox dot com"> wrote:
> if memory serves me right), this is installed under:
> C:\Program Files\ActiveState\perl\bin
Where the perl binary is installed is not relevant to relative paths.
> Since this box is hosted and I only have FTP access, I don't have the
> ability to set environment variables.
Did somebody mention environment variables somewhere?
You can set them inside your Perl program just fine:
$ENV{SOME_ENV_VAR} = 'some value';
> It's also a Windows box, so I
> don't think I can execute shell commands with backticks.
Backticks should work fine on Windows.
Have you tried it?
Neither env vars nor backticks is relevant to relative paths.
> The perl script resides in:
> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
Where your Perl program is installed is not relevant to relative paths.
What is relevant to relative paths is your current working directory.
What is relevant to relative paths is your current working directory.
What is relevant to relative paths is your current working directory.
What is your current working directory?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 15 Jan 2009 13:44:52 +1300
From: "Tintin@teranews.com" <Tintin@teranews.com>
Subject: Re: unable to open file
Message-Id: <bGvbl.76459$ln7.50155@newsfe04.iad>
Tad J McClellan wrote:
> Ken Teague <"kteague at pobox dot com"> wrote:
>> The perl script resides in:
>> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
>
>
> Where your Perl program is installed is not relevant to relative paths.
>
>
> What is relevant to relative paths is your current working directory.
>
> What is relevant to relative paths is your current working directory.
>
> What is relevant to relative paths is your current working directory.
>
> What is your current working directory?
Tad makes a very good point. Under some IIS (which I assume is the
webserver you are using), quite often the current working directory for
CGI programs is the Web Document Root and not the directory the script
lives in.
------------------------------
Date: Thu, 15 Jan 2009 13:49:41 +1300
From: "Tintin@teranews.com" <Tintin@teranews.com>
Subject: Re: unable to open file
Message-Id: <IKvbl.15939$HD7.4869@newsfe25.iad>
Tintin@teranews.com wrote:
> Tad J McClellan wrote:
>> Ken Teague <"kteague at pobox dot com"> wrote:
>
>>> The perl script resides in:
>>> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
>>
>>
>> Where your Perl program is installed is not relevant to relative paths.
>>
>>
>> What is relevant to relative paths is your current working directory.
>>
>> What is relevant to relative paths is your current working directory.
>>
>> What is relevant to relative paths is your current working directory.
>>
>> What is your current working directory?
>
> Tad makes a very good point. Under some IIS (which I assume is the
> webserver you are using), quite often the current working directory for
> CGI programs is the Web Document Root and not the directory the script
> lives in.
Forgot to mention that the standard Perl FindBin module is useful for
working out working directories.
------------------------------
Date: Wed, 14 Jan 2009 17:01:26 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <sf2tm4hmqkbrq6hkjcj1s9umpicghv6rsn@4ax.com>
Ken Teague <"kteague at pobox dot com"> wrote:
>Since this is a hosted server and I only have FTP access, I was able to
>determine it's running ActiveState perl v5.8.7. In my experience (and
>if memory serves me right), this is installed under:
> C:\Program Files\ActiveState\perl\bin
Irrelevant.
>Since this box is hosted and I only have FTP access, I don't have the
>ability to set environment variables.
Why not? How does your ISP block you you from modifying %ENV? I would
think that's impossible.
>It's also a Windows box, so I
>don't think I can execute shell commands with backticks.
Why do you think so? Have you tried it? It works just fine...
>The web root is:
> E:\0\0\25\44\188533\user\191178\htdocs
Irrelevant
>... and there's a cgi-bin directory underneath it:
> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
Irrelevant
>The perl script resides in:
> E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin
Irrelevant
>E:\0\0\25\44\188533\user\191178\htdocs\cgi-bin contains the following:
> csvsearch.pl
> prodscript.html
> products.txt
Irrelevant.
>csvsearch.pl is, of course, the perl script we're dealing with.
>prodscript.html is the web page that csvsearch.pl gives its data to and
>is the "search results" page. products.txt is a simple text file
>containing product IDs and description in this format:
> productID|description|productID.pdf
>... for example:
> 227229|PRETREATMENT CARPET 28H 34858 3M TWIST'N 62L|227229.pdf
> 350111|POLISH SS AERO 14002 3M 1221oz|350111.pdf
Irrelevant.
As people have told you several times WHAT IS YOUR CURRENT WORKING
DIRECTORY (CWD)? Any relative path will be relative to the CWD and
nothing else.
jue
------------------------------
Date: Wed, 14 Jan 2009 17:06:47 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: unable to open file
Message-Id: <5t2tm414ugib2q6beablrip1lnal147nve@4ax.com>
"Tintin@teranews.com" <Tintin@teranews.com> wrote:
>Forgot to mention that the standard Perl FindBin module is useful for
>working out working directories.
How so? At least the version I am looking at states
FindBin - Locate directory of original perl script
It doesn't mention any function related to the CWD.
jue
------------------------------
Date: Wed, 14 Jan 2009 19:21:43 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: unable to open file
Message-Id: <slrngmt3t7.9d4.tadmc@tadmc30.sbcglobal.net>
Tintin@teranews.com <Tintin@teranews.com> wrote:
> Forgot to mention that the standard Perl FindBin module is useful for
> working out working directories.
No it isn't.
It is useful for allowing relative paths in "use lib".
It does not help with normal filesystem access.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 14 Jan 2009 13:34:32 -0800 (PST)
From: Bill H <bill@ts1000.us>
Subject: Re: Using exec()
Message-Id: <2544da32-be11-4f07-9f82-f4aa36534b34@r36g2000prf.googlegroups.com>
On Jan 14, 12:12=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> Bill H <b...@ts1000.us> wrote:
> >According to the perldoc exec() never returns when it is called,
>
> No. It never returns if the call was successfull. That is different.
>
> >which
> >is fine, but I can't see anywhere if the calling script will continue
> >on or does it stop when you do the exec.
>
> Well, if the call doesn't return, then how could the script continue?
> In any case, what happens behind the scenes is that your Perl code is
> being replaced(!) by the called external program and the process starts
> executing that new code.
>
> >Will the exec let me start another perl script
> >but allow the calling script to finish up and exit as if it had never
> >called an exec?
>
> No. exec() replaces the code and the old code is gone. I think you may
> be looking for system() instead of for exec().
>
> jue
Jurgen, from your response and the others (thank you), I see I have to
use system() in some manner with fork() to get what I want.
An example using exec()
print "hello ";
exec("perl otherscript.pm");
print "world"; # World never prints
An example using system()
print "hello ";
system("perl otherscript.pm");
print "world "; # World prints when otherscript.pm is done
What I need to do:
print "hello ";
not_exec_or_system("perl otherscript,pm");
print "world"; # World prints immediately and otherscript.pm is
running also
Bill H
------------------------------
Date: Wed, 14 Jan 2009 21:49:44 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Using exec()
Message-Id: <gklmlo$neq$1@reader1.panix.com>
In article <2544da32-be11-4f07-9f82-f4aa36534b34@r36g2000prf.googlegroups.com>,
Bill H <bill@ts1000.us> wrote:
>What I need to do:
>
>print "hello ";
>not_exec_or_system("perl otherscript,pm");
>print "world"; # World prints immediately and otherscript.pm is
As Joost Diepenmaat <joost@zeekat.nl> wrote, you may be able to do
that with
print "hello ";
system("perl otherscript.pm &");
print "world"; # World prints immediately and
# otherscript.pm is running also
That presumes that your system's command interpreter uses terminal "&"
to run a program in background: that works on Linux but not Windows
cmd.exe. It also doesn't allow you to monitor the progress of
otherscript.pm: neither the caller nor anything else can tell whether
it's still running (except for heroic measures, or unless it itself
signals its progress via a status file), or whether it ends with an
error exit (even something like otherscript.pm not being an existing
file, so it dies at once).
If one of those conditions doesn't work for you, then you have to
implement the "&" functionality yourself.
- Method 1: use fork(). The parent does NOT wait() or
waitpid() for the child. The child does an exec() of
perl otherscript.pm.
- Method 2: use fork(). The parent does NOT wait() or
waitpid() for the child. The child does a system() of
perl otherscript.pm. The child examines the return value of
system() to see whether it was a "crash on takeoff", or whether
there was a non-zero exit status, or a normal run, and does whatever
seems indicated (log an error, e-mail someone, whatever). The child
ends with an exit().
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 14 Jan 2009 14:15:07 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Using exec()
Message-Id: <5posm4lln4r9dibvrh0h4i9nmaso83pi15@4ax.com>
Bill H <bill@ts1000.us> wrote:
>Jurgen, from your response and the others (thank you), I see I have to
>use system() in some manner with fork() to get what I want.
Well, maybe.
>What I need to do:
>
>print "hello ";
>not_exec_or_system("perl otherscript,pm");
>print "world"; # World prints immediately and otherscript.pm is
>running also
So you want that other program and the calling script to run in
parallel, in particular you don't want the calling script to wait until
the other program has finished. Is this correct?
If yes, then yes, you could use fork() and then exec() the other program
in the child process.
Or you could start the other program using system() and run it in the
background using whatever method your command shell and/or OS provides
to run programs in the background.
Both methods are valid and will work.
jue
------------------------------
Date: Wed, 14 Jan 2009 17:39:28 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Using exec()
Message-Id: <slrngmsttg.6un.tadmc@tadmc30.sbcglobal.net>
Bill H <bill@ts1000.us> wrote:
> I see
You are not yet seeing correctly.
> I have to
> use system() in some manner with fork() to get what I want.
You have to use exec() in some manner with fork() or use system()
and put the process into the background.
> An example using exec()
Where's the fork() that you said you needed with exec()?
> print "hello ";
> exec("perl otherscript.pm");
> print "world"; # World never prints
>
> An example using system()
>
> print "hello ";
> system("perl otherscript.pm");
system('perl otherscript.pm &');
> print "world "; # World prints when otherscript.pm is done
print "world "; # World prints immediately and otherscript.pm is running also
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: 15 Jan 2009 01:09:29 GMT
From: xhoster@gmail.com
Subject: Re: Using exec()
Message-Id: <20090114201200.596$GY@newsreader.com>
Tad J McClellan <tadmc@seesig.invalid> wrote:
> Bill H <bill@ts1000.us> wrote:
>
> > I see
>
> You are not yet seeing correctly.
>
> > I have to
> > use system() in some manner with fork() to get what I want.
>
> You have to use exec() in some manner with fork() or use system()
> and put the process into the background.
>
> > An example using exec()
>
> Where's the fork() that you said you needed with exec()?
It's not there. He is showing examples of what he tried that didn't work,
which lead him to conclude he needed fork. I thought that was pretty
obvious. More people should show us how they reached their conclusions,
so we can point out if they are mistaken.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Wed, 14 Jan 2009 17:17:57 -0800
From: Tim Greer <tim@burlyhost.com>
Subject: Re: Using exec()
Message-Id: <99wbl.49664$tD1.2245@newsfe07.iad>
xhoster@gmail.com wrote:
> Tad J McClellan <tadmc@seesig.invalid> wrote:
>> Bill H <bill@ts1000.us> wrote:
>>
>> > I see
>>
>> You are not yet seeing correctly.
>>
>> > I have to
>> > use system() in some manner with fork() to get what I want.
>>
>> You have to use exec() in some manner with fork() or use system()
>> and put the process into the background.
>>
>> > An example using exec()
>>
>> Where's the fork() that you said you needed with exec()?
>
> It's not there. He is showing examples of what he tried that didn't
> work,
> which lead him to conclude he needed fork. I thought that was pretty
> obvious. More people should show us how they reached their
> conclusions, so we can point out if they are mistaken.
>
> Xho
>
I thought it was pretty straight forward as well, but I seem to be
having trouble wording things today myself, so I suppose people could
have read it differently (and clearly did).
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
------------------------------
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 2127
***************************************
