Matthew Woehlke wrote:
>>> clemens fischer writes:
>>>
>>>> I have the following construct in a script:
>>>>
>>>> ... a number of commands
>>>> {
>>>> ... a number of commands
>>>> } 2>&1 | ${prog_log} "${logfile}"
>>>>
>>>> It seems anything inside the braces is not seen by bash, and it
>>>> doesn't show up in a "sh -x ..." trace, but ${prog_log} does. I
>>>> had debug echo's at the start of the block, they aren't triggered.
>
> This sort of construct seems to be working fine for me. Note that the
> contents of the block are executed in a subshell, and using 'true' as
> prog_log will suppress both stdout and stderr, as set up (though you
> might get a broken pipe error). So unless the commands in the block
> have side effects observable outside of the script, you won't know
> whether or not they execute.
Greg Wooledge observed in a private email that the parts of a pipeline
are executed in subshells. Presumably he thinks that I set "prog_log"
in the feeder end rendering it without a defined value in the consumer,
but this variable is a global available to both.
But you made me see the light anyway! Actually the logger was "system
${prog_log} "${logfile}"", with "system" being the customary
system()
{
local cur_fun="${FUNCNAME[0]}"
local ex=0
msg "$*"
[ ${opt_dryrun} -gt 0 ] && return 0
type -t "${1}" >/dev/null 2>&1 && {
eval "$@" || {
ex=$?
msg "$* exits ${ex}"
}
} || {
msg "${1} undefined $?"
ex=9999
}
return ${ex}
}
and "msg" sending output to "1>&2". As the script failed both with and
without that "system" prefix, I thought it didn't matter. I thought the
commands in "system" are neutral to any data on stdin until the eval is
reached.
Now what I needed to have both normal and dry-run working is setting the
logger to "cat" and unsetting logfile for the latter case, then
{ ... } 2>&1 | ${prog_log} ${logfile+"${logfile}"}
does what I mean. Does somebody know what's wrong with "system()" when
given data on stdin to be given to "eval"?
clemens
