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










share|improve this question






















  • 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






  • 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 nohup command-line utility. It
    – ikegami
    Nov 19 at 23:57















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










share|improve this question






















  • 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






  • 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 nohup command-line utility. It
    – ikegami
    Nov 19 at 23:57













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










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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/null ever 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 nohup command-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










  • @tink Your answer scared me, does > /dev/null ever 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 nohup command-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












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.






share|improve this answer





















  • 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











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















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

























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.






share|improve this answer





















  • 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















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.






share|improve this answer





















  • 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













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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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/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


















  • 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
















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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Feedback on college project

Futebolista

Albești (Vaslui)