Thanks to all who replied - I tried most, but not all suggestions
The good news is I got the bug fixed.
It's pretty clear that 'stdin' was getting 'drained' somewhere down the
stack (I'm still now sure where), as John M. suggested.
Using another file descriptor instead of stdin (0) worked around the issue:
*exec 3<&0 * # Link file descriptor #3 with
stdin.
local nextLine
while read -u 3 nextLine; do
zVerbose "calling zSetOneSystem $nextLine"
zSetOneSystem $nextLine
done *3<* <(echo "$expList") # read from expList on file
descriptor 3
On Thu, May 4, 2017 at 10:40 AM, Neale Ferguson <ne...@sinenomine.net>
wrote:
> Rather than using read can you load the results of the command into an
> array and iterate:
>
>
> FILES=`ls`
>
> FILE=(${FILES})
>
> for ((i=0; i<${#FILE[@]}; i++))
>
> do
>
> echo ${i} ${FILE[$i]}
>
> done
>
> Exit
>
>
> This should load the variables before the other scripts are invoked.
>
>
> Neale
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
--
-Mike MacIsaac
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
