> > 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
> functi
> ons
> (outside perhaps of an expensive book which I don't have), I wonder if that
> migh
> t
> not be a typo for $@ (vice @). However, I wonder if that would do anything
> (da
> rn
> 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...
This was a typo I meant to type $@, not @ but if I had done this
it would be a mistake. It should be eval "${.sh.value}" |&
as you suggest.
>
> There seems to be something that prevents recursion within a get discipline
> func
> tion;
Discipline functions are not called recursively for the same
function, but you can call a get function from within a set discipline
for the same variable.
In ksh93s, you can call the discipline function with different
subscripts of the same array.
> at least, when I try to play with this, it doesn't hang. I'm guessing that's
> ab
> out preserving
> the output already seen; however, it doesn't work, as the value of foo at
> that p
> oint 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
> no
> t
> all that generalizable. Not to mention that with the timeout on the read
> (neede
> d to
> keep it from blocking, I guess), this isn't very efficient, either.
I agree that it is not very efficient since it uses a busy wait.
You can have multiple |& at the same time if you move the file descriptors
with >& p and <& p.
>
>
> This message posted from opensolaris.org
David Korn
dgk at research.att.com
