Catch result of sub-process in Z-shell

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












AAA <options>; CCC AAA <options>


AAA, CCC are different commands.



Here we're in an zsh script - for example:



vi script.zsh
<...>
AAA <options>; CCC AAA <options>
<...>


Verbose: Correct me if I'm wrong, CCC AAA <options>'s AAA <options> will be using a subshell and then create a separated process from current shell or may be using current shell and then create a sub-process from the process that running current script.



The problem is that CCC will stay alive after script.zsh is finished. This causes problem that when I try to call something that as result - not the return value (it did create something after done - a newly created object for i.e) of CCC AAA <options>'s AAA <options> INSIDE script.zsh causing not found warning.



That's being said, how to make current script.zsh can see the result of 'AAA <options>'?



If possible target the Z-shell.



EDIT:
Should be:



AAA <options>; CCC AAA <options>









share|improve this question























  • what result? standard out? err? both? the exit status code?
    – thrig
    Sep 13 at 13:45














up vote
0
down vote

favorite












AAA <options>; CCC AAA <options>


AAA, CCC are different commands.



Here we're in an zsh script - for example:



vi script.zsh
<...>
AAA <options>; CCC AAA <options>
<...>


Verbose: Correct me if I'm wrong, CCC AAA <options>'s AAA <options> will be using a subshell and then create a separated process from current shell or may be using current shell and then create a sub-process from the process that running current script.



The problem is that CCC will stay alive after script.zsh is finished. This causes problem that when I try to call something that as result - not the return value (it did create something after done - a newly created object for i.e) of CCC AAA <options>'s AAA <options> INSIDE script.zsh causing not found warning.



That's being said, how to make current script.zsh can see the result of 'AAA <options>'?



If possible target the Z-shell.



EDIT:
Should be:



AAA <options>; CCC AAA <options>









share|improve this question























  • what result? standard out? err? both? the exit status code?
    – thrig
    Sep 13 at 13:45












up vote
0
down vote

favorite









up vote
0
down vote

favorite











AAA <options>; CCC AAA <options>


AAA, CCC are different commands.



Here we're in an zsh script - for example:



vi script.zsh
<...>
AAA <options>; CCC AAA <options>
<...>


Verbose: Correct me if I'm wrong, CCC AAA <options>'s AAA <options> will be using a subshell and then create a separated process from current shell or may be using current shell and then create a sub-process from the process that running current script.



The problem is that CCC will stay alive after script.zsh is finished. This causes problem that when I try to call something that as result - not the return value (it did create something after done - a newly created object for i.e) of CCC AAA <options>'s AAA <options> INSIDE script.zsh causing not found warning.



That's being said, how to make current script.zsh can see the result of 'AAA <options>'?



If possible target the Z-shell.



EDIT:
Should be:



AAA <options>; CCC AAA <options>









share|improve this question















AAA <options>; CCC AAA <options>


AAA, CCC are different commands.



Here we're in an zsh script - for example:



vi script.zsh
<...>
AAA <options>; CCC AAA <options>
<...>


Verbose: Correct me if I'm wrong, CCC AAA <options>'s AAA <options> will be using a subshell and then create a separated process from current shell or may be using current shell and then create a sub-process from the process that running current script.



The problem is that CCC will stay alive after script.zsh is finished. This causes problem that when I try to call something that as result - not the return value (it did create something after done - a newly created object for i.e) of CCC AAA <options>'s AAA <options> INSIDE script.zsh causing not found warning.



That's being said, how to make current script.zsh can see the result of 'AAA <options>'?



If possible target the Z-shell.



EDIT:
Should be:



AAA <options>; CCC AAA <options>






shell zsh subshell






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 14 at 10:10

























asked Sep 13 at 11:50









Tuyen Pham

30510




30510











  • what result? standard out? err? both? the exit status code?
    – thrig
    Sep 13 at 13:45
















  • what result? standard out? err? both? the exit status code?
    – thrig
    Sep 13 at 13:45















what result? standard out? err? both? the exit status code?
– thrig
Sep 13 at 13:45




what result? standard out? err? both? the exit status code?
– thrig
Sep 13 at 13:45










1 Answer
1






active

oldest

votes

















up vote
1
down vote













No,



CCC 'AAA <options>'


Starts CCC with one literal AAA <options> argument. That's the same in every shell. You can verify by using the echo command in place of CCC:



$ echo 'AAA <options>'
AAA <options>


If you wanted to call CCC with the output (without the trailing newline characters) of AAA as one single argument, you'd do:



CCC "$(AAA <options>)"


If you wanted to call CCC with as many words as there are in the output of AAA (space, tab, newline, NUL separated), you'd do:



CCC $(AAA <options>)


In any case, CCC won't be started until AAA has returned and the script won't terminate until CCC has returned.



For a script to terminate before a command returns, you'd need it to start that command asynchronously like with:



CCC args &


In any case, that's the same in every shell, it's not zsh specific (except for that splitting on NUL above).






share|improve this answer




















  • I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
    – Tuyen Pham
    Sep 14 at 10:10










  • I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
    – Tuyen Pham
    Sep 14 at 10:17











  • @TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
    – Stéphane Chazelas
    Sep 14 at 10:31










  • True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
    – Tuyen Pham
    Sep 14 at 10:42










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f468777%2fcatch-result-of-sub-process-in-z-shell%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













No,



CCC 'AAA <options>'


Starts CCC with one literal AAA <options> argument. That's the same in every shell. You can verify by using the echo command in place of CCC:



$ echo 'AAA <options>'
AAA <options>


If you wanted to call CCC with the output (without the trailing newline characters) of AAA as one single argument, you'd do:



CCC "$(AAA <options>)"


If you wanted to call CCC with as many words as there are in the output of AAA (space, tab, newline, NUL separated), you'd do:



CCC $(AAA <options>)


In any case, CCC won't be started until AAA has returned and the script won't terminate until CCC has returned.



For a script to terminate before a command returns, you'd need it to start that command asynchronously like with:



CCC args &


In any case, that's the same in every shell, it's not zsh specific (except for that splitting on NUL above).






share|improve this answer




















  • I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
    – Tuyen Pham
    Sep 14 at 10:10










  • I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
    – Tuyen Pham
    Sep 14 at 10:17











  • @TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
    – Stéphane Chazelas
    Sep 14 at 10:31










  • True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
    – Tuyen Pham
    Sep 14 at 10:42














up vote
1
down vote













No,



CCC 'AAA <options>'


Starts CCC with one literal AAA <options> argument. That's the same in every shell. You can verify by using the echo command in place of CCC:



$ echo 'AAA <options>'
AAA <options>


If you wanted to call CCC with the output (without the trailing newline characters) of AAA as one single argument, you'd do:



CCC "$(AAA <options>)"


If you wanted to call CCC with as many words as there are in the output of AAA (space, tab, newline, NUL separated), you'd do:



CCC $(AAA <options>)


In any case, CCC won't be started until AAA has returned and the script won't terminate until CCC has returned.



For a script to terminate before a command returns, you'd need it to start that command asynchronously like with:



CCC args &


In any case, that's the same in every shell, it's not zsh specific (except for that splitting on NUL above).






share|improve this answer




















  • I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
    – Tuyen Pham
    Sep 14 at 10:10










  • I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
    – Tuyen Pham
    Sep 14 at 10:17











  • @TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
    – Stéphane Chazelas
    Sep 14 at 10:31










  • True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
    – Tuyen Pham
    Sep 14 at 10:42












up vote
1
down vote










up vote
1
down vote









No,



CCC 'AAA <options>'


Starts CCC with one literal AAA <options> argument. That's the same in every shell. You can verify by using the echo command in place of CCC:



$ echo 'AAA <options>'
AAA <options>


If you wanted to call CCC with the output (without the trailing newline characters) of AAA as one single argument, you'd do:



CCC "$(AAA <options>)"


If you wanted to call CCC with as many words as there are in the output of AAA (space, tab, newline, NUL separated), you'd do:



CCC $(AAA <options>)


In any case, CCC won't be started until AAA has returned and the script won't terminate until CCC has returned.



For a script to terminate before a command returns, you'd need it to start that command asynchronously like with:



CCC args &


In any case, that's the same in every shell, it's not zsh specific (except for that splitting on NUL above).






share|improve this answer












No,



CCC 'AAA <options>'


Starts CCC with one literal AAA <options> argument. That's the same in every shell. You can verify by using the echo command in place of CCC:



$ echo 'AAA <options>'
AAA <options>


If you wanted to call CCC with the output (without the trailing newline characters) of AAA as one single argument, you'd do:



CCC "$(AAA <options>)"


If you wanted to call CCC with as many words as there are in the output of AAA (space, tab, newline, NUL separated), you'd do:



CCC $(AAA <options>)


In any case, CCC won't be started until AAA has returned and the script won't terminate until CCC has returned.



For a script to terminate before a command returns, you'd need it to start that command asynchronously like with:



CCC args &


In any case, that's the same in every shell, it's not zsh specific (except for that splitting on NUL above).







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 13 at 16:17









Stéphane Chazelas

286k53528867




286k53528867











  • I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
    – Tuyen Pham
    Sep 14 at 10:10










  • I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
    – Tuyen Pham
    Sep 14 at 10:17











  • @TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
    – Stéphane Chazelas
    Sep 14 at 10:31










  • True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
    – Tuyen Pham
    Sep 14 at 10:42
















  • I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
    – Tuyen Pham
    Sep 14 at 10:10










  • I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
    – Tuyen Pham
    Sep 14 at 10:17











  • @TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
    – Stéphane Chazelas
    Sep 14 at 10:31










  • True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
    – Tuyen Pham
    Sep 14 at 10:42















I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
– Tuyen Pham
Sep 14 at 10:10




I edited the 1st post, it's actually AAA <options>; CCC AAA <options>
– Tuyen Pham
Sep 14 at 10:10












I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
– Tuyen Pham
Sep 14 at 10:17





I found out that I assumed that CCC AAA <options> had completed and object had been created but that's not true, I had to put while loop to test against the exsiting of the object and wait till it completely created before do other task so the question is why I put the command to process against object after the CCC AAA <options>, zsh shell did not wait till the process to complete to move to next command that make me conclude AAA <options> might run in a sub-process or a separated shell. Is that true?
– Tuyen Pham
Sep 14 at 10:17













@TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
– Stéphane Chazelas
Sep 14 at 10:31




@TuyenPham, not sure what you mean AAA <options> starts AAA with <options> as argument in a child process and zsh waits for the child process to return, CCC AAA <options> starts CCC with AAA, <options> as arguments and zsh waits for that process to return. Whether CCC treats its first argument as a command name is not known to zsh. CCC may itself fork child processes that keep running after their parent dies, but again zsh or any other shell would not know nor care about them.
– Stéphane Chazelas
Sep 14 at 10:31












True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
– Tuyen Pham
Sep 14 at 10:42




True, zsh seems doesn't care, probably here CCC did a fork process to process AAA <options> and the AAA <options> took longer to process of CCC . That caused the problem.
– Tuyen Pham
Sep 14 at 10:42

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f468777%2fcatch-result-of-sub-process-in-z-shell%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay