> On 11/27/06, David Korn <dgk at research.att.com> wrote: > > > > > Does ksh93 have a function to handle variables > like files? I'd like to > > > output sub process data to a variable which > should be updated for each > > > further write from the child. foo=$(ls -l) sends > all output after the > > > child terminates but I'd like to run the child in > the background and > > > $foo always reflects the whole output up to the > moment. > > > > > > Josh > > > > No, but you can come somewhat close to what I think > you are asking > > for using discipline functions. For example, > > > > function foo.set > > { > > eval "@" |& > > I don't grok. What does the eval "@" do?
While I wouldn't presume to correct dgk (unlike some turkeys that work at M$!), especially since I've had little like finding documentation on discipline functions (outside perhaps of an expensive book which I don't have), I wonder if that might not be a typo for $@ (vice @). However, I wonder if that would do anything (darn if I can tell what the args to a set discipline function are); perhaps it should be eval "${.sh.value}" |& > > } > > function foo.get > > { > > .sh.value=$foo > > isn't this recursive? $foo calls foo.get which uses > $foo which calls > foo.get which uses... There seems to be something that prevents recursion within a get discipline function; at least, when I try to play with this, it doesn't hang. I'm guessing that's about preserving the output already seen; however, it doesn't work, as the value of foo at that point is the command originally assigned to foo (at least with the "Version M 1993-12-28 o+" that I have to play with). > > > while read -t.01 -r -p > > do .sh.value+=$REPLY$'\n' > > done > > } > > Why don't you use .sh.value="$(cat foo)" here? I think that would only set foo once with all the output rather than update it incrementally. However, neglecting that line that I already said didn't work, I only get output not already seen, i.e. if I use function foo.set { eval "${.sh.value}" |& } function foo.get { .sh.value="${foo}" while read -t .01 -r -p do .sh.value+="$REPLY"$'\n' done } and where the command "slow" is something like #! /bin/ksh93 typeset -i x=0 while ((x<30)) do print -r -- "$x" sleep 1 let x+=1 done if I do foo=slow;print -r -- "$foo" I might get 0 1 2 3 the first time, and on a subsequent print -r -- "$foo" get 4 5 6 and so on. Also, insofar as one can only have one |& process at once (as far as I know, not having played with them before), the notion of all this is interesting, but arguably not all that generalizable. Not to mention that with the timeout on the read (needed to keep it from blocking, I guess), this isn't very efficient, either. This message posted from opensolaris.org