Can I capture the output of another process that I started?
up vote
0
down vote
favorite
I'm currently using > /dev/null & to have Perl script A run Perl script B totally independently, and it works fine. Script B runs without throwing back any output and stays alive when Script A ends, even when my terminal session ends.
Not saying I need it, but is there a way to recapture its output if I wanted to?
Thanks
linux perl system
add a comment |
up vote
0
down vote
favorite
I'm currently using > /dev/null & to have Perl script A run Perl script B totally independently, and it works fine. Script B runs without throwing back any output and stays alive when Script A ends, even when my terminal session ends.
Not saying I need it, but is there a way to recapture its output if I wanted to?
Thanks
linux perl system
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
@tink Your answer scared me, does> /dev/nullever fill up?
– Sergio D. Caplan
Nov 19 at 18:54
3
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
If you want to start a program in the background, look at thenohupcommand-line utility. It
– ikegami
Nov 19 at 23:57
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm currently using > /dev/null & to have Perl script A run Perl script B totally independently, and it works fine. Script B runs without throwing back any output and stays alive when Script A ends, even when my terminal session ends.
Not saying I need it, but is there a way to recapture its output if I wanted to?
Thanks
linux perl system
I'm currently using > /dev/null & to have Perl script A run Perl script B totally independently, and it works fine. Script B runs without throwing back any output and stays alive when Script A ends, even when my terminal session ends.
Not saying I need it, but is there a way to recapture its output if I wanted to?
Thanks
linux perl system
linux perl system
asked Nov 19 at 18:50
Sergio D. Caplan
176110
176110
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
@tink Your answer scared me, does> /dev/nullever fill up?
– Sergio D. Caplan
Nov 19 at 18:54
3
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
If you want to start a program in the background, look at thenohupcommand-line utility. It
– ikegami
Nov 19 at 23:57
add a comment |
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
@tink Your answer scared me, does> /dev/nullever fill up?
– Sergio D. Caplan
Nov 19 at 18:54
3
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
If you want to start a program in the background, look at thenohupcommand-line utility. It
– ikegami
Nov 19 at 23:57
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
@tink Your answer scared me, does
> /dev/null ever fill up?– Sergio D. Caplan
Nov 19 at 18:54
@tink Your answer scared me, does
> /dev/null ever fill up?– Sergio D. Caplan
Nov 19 at 18:54
3
3
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
If you want to start a program in the background, look at the
nohup command-line utility. It– ikegami
Nov 19 at 23:57
If you want to start a program in the background, look at the
nohup command-line utility. It– ikegami
Nov 19 at 23:57
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
Your code framework may look like this:
#!/usr/bin/perl
# I'm a.pl
#...
system "b.pl > ~/b.out &";
while (1)
{
my $time = localtime;
my ($fsize, $mtime) = (stat "/var/log/syslog")[7,9];
print "syslog: size=$fsize, mtime=$mtime at $timen";
sleep 60;
}
while the b.pl may look like:
#!/usr/bin/perl
# I'm b.pl
while (1)
{
my $time = localtime;
my $fsize_a = (stat "/var/log/auth.log")[7];
my $fsize_s = (stat "/var/log/syslog")[7];
print "fsize: syslog=$fsize_s auth.log=$fsize_a at $timen";
sleep 60;
}
- a.pl and b.pl do their job independently.
- b.pl is called by a.pl as a background job, which sends its output to b.out(won't mess up the screen of a.pl)
- You can read b.out from some other terminal, or after a.pl is finished(or when a.pl is put to background temporarily)
About terminating the two scripts:
- `ctrl-c` for a.pl
- `killall b.pl` for b.pl
Note:
- b.pl will never terminate even when you terminate your terminal (Assumed that your terminal is run as a desktop application), so you don't need the `nohup` command to help. (Perhaps only useful in console)
- If your b.pl may spit out error messages from time to time, then you still need to deal with its stderr. It's left as your homework.
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using> /dev/nullas default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.
– Charles Jie
Nov 21 at 2:24
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Your code framework may look like this:
#!/usr/bin/perl
# I'm a.pl
#...
system "b.pl > ~/b.out &";
while (1)
{
my $time = localtime;
my ($fsize, $mtime) = (stat "/var/log/syslog")[7,9];
print "syslog: size=$fsize, mtime=$mtime at $timen";
sleep 60;
}
while the b.pl may look like:
#!/usr/bin/perl
# I'm b.pl
while (1)
{
my $time = localtime;
my $fsize_a = (stat "/var/log/auth.log")[7];
my $fsize_s = (stat "/var/log/syslog")[7];
print "fsize: syslog=$fsize_s auth.log=$fsize_a at $timen";
sleep 60;
}
- a.pl and b.pl do their job independently.
- b.pl is called by a.pl as a background job, which sends its output to b.out(won't mess up the screen of a.pl)
- You can read b.out from some other terminal, or after a.pl is finished(or when a.pl is put to background temporarily)
About terminating the two scripts:
- `ctrl-c` for a.pl
- `killall b.pl` for b.pl
Note:
- b.pl will never terminate even when you terminate your terminal (Assumed that your terminal is run as a desktop application), so you don't need the `nohup` command to help. (Perhaps only useful in console)
- If your b.pl may spit out error messages from time to time, then you still need to deal with its stderr. It's left as your homework.
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using> /dev/nullas default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.
– Charles Jie
Nov 21 at 2:24
add a comment |
up vote
0
down vote
Your code framework may look like this:
#!/usr/bin/perl
# I'm a.pl
#...
system "b.pl > ~/b.out &";
while (1)
{
my $time = localtime;
my ($fsize, $mtime) = (stat "/var/log/syslog")[7,9];
print "syslog: size=$fsize, mtime=$mtime at $timen";
sleep 60;
}
while the b.pl may look like:
#!/usr/bin/perl
# I'm b.pl
while (1)
{
my $time = localtime;
my $fsize_a = (stat "/var/log/auth.log")[7];
my $fsize_s = (stat "/var/log/syslog")[7];
print "fsize: syslog=$fsize_s auth.log=$fsize_a at $timen";
sleep 60;
}
- a.pl and b.pl do their job independently.
- b.pl is called by a.pl as a background job, which sends its output to b.out(won't mess up the screen of a.pl)
- You can read b.out from some other terminal, or after a.pl is finished(or when a.pl is put to background temporarily)
About terminating the two scripts:
- `ctrl-c` for a.pl
- `killall b.pl` for b.pl
Note:
- b.pl will never terminate even when you terminate your terminal (Assumed that your terminal is run as a desktop application), so you don't need the `nohup` command to help. (Perhaps only useful in console)
- If your b.pl may spit out error messages from time to time, then you still need to deal with its stderr. It's left as your homework.
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using> /dev/nullas default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.
– Charles Jie
Nov 21 at 2:24
add a comment |
up vote
0
down vote
up vote
0
down vote
Your code framework may look like this:
#!/usr/bin/perl
# I'm a.pl
#...
system "b.pl > ~/b.out &";
while (1)
{
my $time = localtime;
my ($fsize, $mtime) = (stat "/var/log/syslog")[7,9];
print "syslog: size=$fsize, mtime=$mtime at $timen";
sleep 60;
}
while the b.pl may look like:
#!/usr/bin/perl
# I'm b.pl
while (1)
{
my $time = localtime;
my $fsize_a = (stat "/var/log/auth.log")[7];
my $fsize_s = (stat "/var/log/syslog")[7];
print "fsize: syslog=$fsize_s auth.log=$fsize_a at $timen";
sleep 60;
}
- a.pl and b.pl do their job independently.
- b.pl is called by a.pl as a background job, which sends its output to b.out(won't mess up the screen of a.pl)
- You can read b.out from some other terminal, or after a.pl is finished(or when a.pl is put to background temporarily)
About terminating the two scripts:
- `ctrl-c` for a.pl
- `killall b.pl` for b.pl
Note:
- b.pl will never terminate even when you terminate your terminal (Assumed that your terminal is run as a desktop application), so you don't need the `nohup` command to help. (Perhaps only useful in console)
- If your b.pl may spit out error messages from time to time, then you still need to deal with its stderr. It's left as your homework.
Your code framework may look like this:
#!/usr/bin/perl
# I'm a.pl
#...
system "b.pl > ~/b.out &";
while (1)
{
my $time = localtime;
my ($fsize, $mtime) = (stat "/var/log/syslog")[7,9];
print "syslog: size=$fsize, mtime=$mtime at $timen";
sleep 60;
}
while the b.pl may look like:
#!/usr/bin/perl
# I'm b.pl
while (1)
{
my $time = localtime;
my $fsize_a = (stat "/var/log/auth.log")[7];
my $fsize_s = (stat "/var/log/syslog")[7];
print "fsize: syslog=$fsize_s auth.log=$fsize_a at $timen";
sleep 60;
}
- a.pl and b.pl do their job independently.
- b.pl is called by a.pl as a background job, which sends its output to b.out(won't mess up the screen of a.pl)
- You can read b.out from some other terminal, or after a.pl is finished(or when a.pl is put to background temporarily)
About terminating the two scripts:
- `ctrl-c` for a.pl
- `killall b.pl` for b.pl
Note:
- b.pl will never terminate even when you terminate your terminal (Assumed that your terminal is run as a desktop application), so you don't need the `nohup` command to help. (Perhaps only useful in console)
- If your b.pl may spit out error messages from time to time, then you still need to deal with its stderr. It's left as your homework.
answered Nov 20 at 11:11
Charles Jie
12
12
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using> /dev/nullas default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.
– Charles Jie
Nov 21 at 2:24
add a comment |
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using> /dev/nullas default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.
– Charles Jie
Nov 21 at 2:24
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
I am using /dev/null as I have no intention of looking at the output, I just mean if I wanted to can I redirect it to something else, then put it back? I don't have to do this, am just curious if I can,
– Sergio D. Caplan
Nov 20 at 19:47
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using
> /dev/null as default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.– Charles Jie
Nov 21 at 2:24
@PlasticProgrammer - You don't have to ALWAYS redirect b.pl's stdout to b.out. You can make an option to turn it on, while using
> /dev/null as default redirection. However, you have to decide how to redirect before you run a.pl. It's not trivial job to switch in midway. And you can not recover anything already sent to /dev/null.– Charles Jie
Nov 21 at 2:24
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380929%2fcan-i-capture-the-output-of-another-process-that-i-started%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Redirect to a file or named pipe instead of /dev/null? With the pipe be cautious, it will fill up and then block by default if not read from.
– tink
Nov 19 at 18:52
@tink Your answer scared me, does
> /dev/nullever fill up?– Sergio D. Caplan
Nov 19 at 18:54
3
No, it doesn't. That's the beauty of it. But what goes to /dev/null stays in /dev/null ;)
– tink
Nov 19 at 18:56
If you want to start a program in the background, look at the
nohupcommand-line utility. It– ikegami
Nov 19 at 23:57