I'm having this same issue. I would like to call a function which has its
STDOUT and STDERR visible on the terminal, yet appended to the log file. And I
want to know if my function finished successfully or had an error. So thinking
I can do the following yet I am caught by this pipe happening after the $? is
read.
# -- attempt 1 ——————————
function foo {
print "in foo\n";
return 1;
}
foo arg1 arg2 | tee -ai a.log 2>&1
rc=$? # pipe returns its return code
print "rc: $rc\n"
(( rc > 0 )) && exit ${rc}
# -- attempt 1 ——————————
Is there a way around this? I tried:
# -- attempt 2 --------------------
integer rc=0
{
foo arg1 arg2
rc=$? # lost at closing brace
} | tee -ai a.log 2>&1
print "rc: $rc\n"
(( rc > 0 )) && exit ${rc}
# -- attempt 2 --------------------
but it prints 0 as the below example does.
I did find one way, but I don't like it.
# -- attempt 3 ——————————
typeset rv=''
integer rc=0
rv=$( foo arg1 arg2 ) # hides actual running in a sub-process, until printed
rc=$?
print "${rv}" | tee -ai a.log 2>&1
print "rc: $rc\n"
(( rc > 0 )) && exit ${rc}
# -- attempt 3 ——————————
but I have a function that takes a long time, I would like to see its progress
on the terminal, instead of waiting for the print to occur after it's all done.
Any other ideas?
# —— output from 1 & 2 ——————————
in foo
rc: 0
# —— output from 1 & 2 ——————————
# —— output from 3 ——————————
in foo
rc: 1
# —— output from 3 ——————————
On 12 Mar 2010, at 13:10 , Cyrille Lefevre wrote:
>
> Heiner Steven a écrit :
>>
>> how could I (in a reliable, portable way) retrieve the exit code of
>> the program "urldecode" in the following code fragment:
>>
>> var=$(echo "$url" | urldecode)
>
> as already said, it's the return code of the last command whatever it is
> a pipeline or not.
>
> however :
>
> typeset var=$(...)
>
> is different than :
>
> typeset var=
> var=$(...)
>
> in the first case, the return code is the one of the typeset command and
> not the one of the var assignment. in other words, if the command fails
> in var assignment (i.e.: var=$(false)) the return code is still 0, since
> the var assignment is right (i.e.: var=something).
> hope I have been enough clear.
>
> Regards,
>
> Cyrille Lefevre
> --
> mailto:[email protected]
>
>
>
> _______________________________________________
> ast-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-users
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users