run application from perl nonblocking?

S

sebastian nielsen

I want to run a command from a perl script in nonblocking mode.
So lets say we have this routine:

sub EndOfBody {
($self, $mailid) = @_;
close(MAILFILE);
#Here I want to run: "C:/parser.exe $mailid"
return(250 , "Mail has been delivered!");
}

At the comment, I want to run the command
C:/parser.exe $mailid

and then instant after launching the command, continue with returning
250 "Mail has been delivered!" while parser.exe is running. (and the
parser.exe should continue running even when the script with the
EndOfBody subroutine has exited)

Since when receiving mails with large attachment, I need to be able to
parse the mail in the background and extract all attachments to a
separate folder, without causing the client to the SMTP server to
timeout.

parser.exe may return something, but it isnt anything useful, so its
no need to take care of the return value from parser.exe
 
B

Ben Morrow

Quoth sebastian nielsen said:
I want to run a command from a perl script in nonblocking mode.
So lets say we have this routine:

sub EndOfBody {
($self, $mailid) = @_;
close(MAILFILE);
#Here I want to run: "C:/parser.exe $mailid"

perldoc -q background

Ben
 
S

sebastian nielsen

I checked it, but system("command &") is a linux-specific command.
Some other guy pointed me to Win32::process, but the question is if
any process lanuched through Win32::process survives when the perl
script exits.
 
J

Jürgen Exner

sebastian nielsen said:
I checked it,

What is "it"? Please quote enough context such that your reply is
understandable on its own.
but system("command &") is a linux-specific command.

Actually it is a shell-specific command. Let me guess: you are trying to
run a command in the background.
Some other guy pointed me to Win32::process,

Let me guess again: you are trying to start a process in the background
on Windows.

Why don't you use the standard Windows method:
system("start command");

jue
 
S

sebastian nielsen

since when running:

system("command");

The perl script will sit there and wait until the started "command"
has finished.
So if "command" takes 1 hour to execute, then the system("command");
in perl will take 1 hour to complete before perl continues too.

What I want to do is to start the "command", release control from the
"command" and then continue running the perl script WHILE "command" is
running.

And "command" should NOT die when the perl script is complete.
 
R

RedGrittyBrick

sebastian nielsen wrote:

Omitted context reinstated - please use a more conventional posting style.

Jürgen Exner wrote
since when running:

system("command");

The perl script will sit there and wait until the started "command"
has finished.
So if "command" takes 1 hour to execute, then the system("command");
in perl will take 1 hour to complete before perl continues too.

What I want to do is to start the "command", release control from the
"command" and then continue running the perl script WHILE "command" is
running.

And "command" should NOT die when the perl script is complete.

You haven't tried what Jürgen suggested!

C:\>perl -e "system('start notepad'); print 'Bye'"
Bye

(After perl exits, Notepad stays on screen and does not die).
 
X

xhoster

sebastian nielsen said:
since when running:

system("command");

That isn't what he suggested you do.

It seems like you are unwilling to uote the material you are allegedly
replying to, nor even bother to read that material.

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.
 
J

Jürgen Exner

sebastian nielsen said:
system("command");

What I want to do is to start the "command", release control from the
"command" and then continue running the perl script WHILE "command" is
running.

Then start 'command' in the background. How to do that depends on your
OS and/or command shell.

jue
 
M

MSwanberg

since when running:

system("command");

The perl script will sit there and wait until the started "command"
has finished.
So if "command" takes 1 hour to execute, then the system("command");
in perl will take 1 hour to complete before perl continues too.

What I want to do is to start the "command", release control from the
"command" and then continue running the perl script WHILE "command" is
running.

And "command" should NOT die when the perl script is complete.


Adding "start" to your command string should do the trick... go to a
command interpreter (DOS box) and type "help start" to get more info.

If you just don't want to do it that way, try forking the perl script
and executing the command from the child fork.

-Mike
 
S

sebastian nielsen

Now I understand.
I tought the whole string "start command" was referring to the command
that should be run, in other words , I tought that I should replace
"start command" with the command I want to run.
Since I didnt know it existed a dos command called "start".

But when providing examples, I understand that I should run "start "
and then the actual command that should execute.

Thanks, its working now.
Now I understand that I should run system("start C:\parse.exe ".
$mailid); and it works like a charm.


BTW, I never quote messages, since I think it takes up unneccesary
space.
 
J

Jim Gibson

sebastian nielsen said:
Now I understand.
I tought the whole string "start command" was referring to the command
that should be run, in other words , I tought that I should replace
"start command" with the command I want to run.
Since I didnt know it existed a dos command called "start".

But when providing examples, I understand that I should run "start "
and then the actual command that should execute.

Thanks, its working now.
Now I understand that I should run system("start C:\parse.exe ".
$mailid); and it works like a charm.


BTW, I never quote messages, since I think it takes up unneccesary
space.

You should be aware that many of the most helpful regulars here (not
me!) do not use Google Groups to read Usenet articles. Other
newsreaders do not present the entire thread to you (and this is a good
thing!) So those helpful others will not have the context of your
posting unless you include the relevant parts with suitable quoting
characters and attribution. Not doing so will make it less likely to
get help from this newsgroup.

Please read the guidelines for this group, posted here regularly.

Thanks.
 
J

Jürgen Exner

sebastian nielsen said:
BTW, I never quote messages,

Good. Because many people do blindly quote the whole message they are
replying to. Propper nettiquette however is asking for quoting the
_relevant_ parts only.
since I think it takes up unneccesary space.

That argument is a red hering. Space for a text message is really
peanuts compared to all those binaries that are posted on Usenet every
day.

But by not quoting the relevant parts of the preceeding message you are
potentially depriving readers of critical information.
Due to the distributed, asynchronous nature of Usenet as well as server
and client configurations there is no telling if a particular reader has
currently access to the preceeding posting, ever had access to it, or
ever will have access.
Besides, even if the preceeding article is currently accessible to a
reader, it is rude to force him to go back to the preceeding article and
read it in its entirety just to be able to understand what you are
talking about.
Not to mention that even after reading the preceeding article he may
still have no idea which part or particular aspect of that article you
are referring to in your reply.

I suggest you may want to reconsider your procedure. There are many
people out there who routinely block people with poor quoting habits.

jue
 
A

Andrew DeFaria

Jürgen Exner said:
That argument is a red hering. Space for a text message is really
peanuts compared to all those binaries that are posted on Usenet every
day.
Great! I'll be sure to reference this next time people use the "space"
argument about posting in HTML... ;-)
But by not quoting the relevant parts of the preceeding message you
are potentially depriving readers of critical information. Due to the
distributed, asynchronous nature of Usenet as well as server and
client configurations there is no telling if a particular reader has
currently access to the preceeding posting, ever had access to it, or
ever will have access.
This seems to rarely be the case anymore...
Besides, even if the preceeding article is currently accessible to a
reader, it is rude to force him to go back to the preceeding article
and read it in its entirety just to be able to understand what you are
talking about.
Hmmm... we don't do this for any other form of communication like phone
calls, etc. People are expected to follow along if they have an
interest. Case in point, if you're listening to a radio talk show and
it's coming close to the end of the hour, is the host required to quote
all previous callers so that somebody who may have come in in the last
second has proper context?

Now I general agree with quoting but I post inline and trim unnecessary
comments. 80-90% of the time most people just quote and do neither.
 
S

szr

Jim said:
You should be aware that many of the most helpful regulars here (not
me!) do not use Google Groups to read Usenet articles.

That's fine, but there are people who do use it. What does that change?
Other newsreaders do not present the entire thread to you (and this
is a good thing!)

How is that possibly a good thing? Why would one not want to at least
have the option of seeing the thread tree? IMHO, any news reader that
cannot show the tree (so that one may see the thread structure) is
incomplete.
 
J

Jürgen Exner

szr said:
That's fine, but there are people who do use it.

Their choice. If they are happy with a slow, cumbersome interface in a
tool that provides no functionality to speak of, then so be it. But even
OE has tons more functionality than that crappy web page.
What does that change?

It changes the perception. Usenet is not a division of Google as some
people seem to believe and the way you see articles organized in Google
is _not_ the typical way people read Usenet.
Typical example:
"But I wrote 3 articles above...." Dude, how would you know which
article is 3 articles above in _MY_ sorting order at _THIS_ point in
time.
How is that possibly a good thing?

Why would I possibly want to wade through and reread a large pile of old
articles in search of new contributions?
Why would one not want to at least
have the option of seeing the thread tree? IMHO, any news reader that
cannot show the tree (so that one may see the thread structure) is
incomplete.

Option to expand the thread including old articles yes. As default view
absolutely no way.
Besides, even expanding the old thread tree works only as long as
articles have not expired, are still available on the server, have not
been filtered, etc., etc.

jue
 
S

szr

Jürgen Exner said:
Their choice. If they are happy with a slow, cumbersome interface in a
tool that provides no functionality to speak of, then so be it. But
even OE has tons more functionality than that crappy web page.
Agreed.


It changes the perception. Usenet is not a division of Google as some
people seem to believe and the way you see articles organized in
Google is _not_ the typical way people read Usenet.

Also agreed.
Typical example:
"But I wrote 3 articles above...." Dude, how would you know which
article is 3 articles above in _MY_ sorting order at _THIS_ point in
time.

Again, agreed; some people who read news groups via Google Groups end up
thinking it is some glorified web forum.
Why would I possibly want to wade through and reread a large pile of
old articles in search of new contributions?

I was talking about a list in which you visibily see the structure of
the thread. You select which article you want to read, but it's nice to
know where you are in the thread.

For example:

First Post | by Foo | date
+ Reply to First | by Bar | date
| + Reply to Reply to First | by Foo | date
+ 2nd Reply to First | by Baz | date
...

How ever it's displayed, any real reader should have some way of showing
you what the thread looks like.
Option to expand the thread including old articles yes.

Yes, this is what I'm talking about.
As default view absolutely no way.

Yes, by default threads should be collapsed. You expand the thread you
want to read.
Besides, even expanding the old thread tree works only as long as
articles have not expired, are still available on the server, have not
been filtered, etc., etc.


This should be a non issue if your reader has proper caching
configuration, allowing you to keep downloaded messages.
 
J

Jim Cochrane

The space wasted for the resulting discussions, just like this one, will
probably total much more than the space you saved by not quoting any
context.
You should be aware that many of the most helpful regulars here (not
me!) do not use Google Groups to read Usenet articles. Other
newsreaders do not present the entire thread to you (and this is a good
thing!) So those helpful others will not have the context of your
posting unless you include the relevant parts with suitable quoting
characters and attribution. Not doing so will make it less likely to
get help from this newsgroup.

In other words, by not quoting context you're greatly increasing the
chances that someone who can answer your question will see your post and
think: "Can't tell what the <...> he's talking about - guess I'll just
move on.", instead of responding with a helpful answer.

Quoting context is a convention and it exists for a good reason. (But
please don't quote the entire article if it's long - that goes to the
other extreme and also breaks convention.)


--
 
P

Peter J. Holzer

I was talking about a list in which you visibily see the structure of
the thread. You select which article you want to read, but it's nice to
know where you are in the thread.

For example:

First Post | by Foo | date
+ Reply to First | by Bar | date
| + Reply to Reply to First | by Foo | date
+ 2nd Reply to First | by Baz | date
...

How ever it's displayed, any real reader should have some way of showing
you what the thread looks like.

Actually, that's not so simple. To do that efficiently requires support
from the news server (or caching all read articles).

Yes, this is what I'm talking about.


Yes, by default threads should be collapsed. You expand the thread you
want to read.

Even in the thread I'm currently reading I prefer to see only the
articles I have not yet read.

hp
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top