Re: [sicsh-develop] Redir and streams

[Gary V. V. <gv...@te...>]

On Thu, Apr 13, 2000 at 04:51:38PM -0400, Ezra Peisach wrote:
> 
> I indicated that I was planning to work on the redir module. (hopefully 
> I will have something working before I leave town next week). 

Anywhere interesting?

> Gary suggested three options for handling output streams:
> 
> >    i)  go ahead and add a FILE* stream for now so that you can keep
> >        going, and we'll worry about snprintfv later.
> >    ii) take a look at snprintfv and install it on your development box,
> >        and reference it as an external library for now.
> >    iii) take the bull by the horns and add snprintfv in a subdirectory,
> >       and make libsic dependent on it.
> 
> I have done a hodgepodge for now, based a little on the snprintv idea
> and a little craziness - which I will probably have to cleanup.

Heh =)O|

> In the struct sic, I have made a pointer to an opaque structure (similar to the
> builtintab) which represent the streams of the particular sic. 

Yup.

> [T]his Streams structure will eventually be made up of structures
> representing input and output streams. (maybe eventually g_stream in snprintv)

Definitely.

> Currently these substructures are a FILE *, a flag indicating if the
> stream needs to be closed (we don't want to close stdout).

Hadn't considered that.  Good point!

> Eventually, I will probably store a filename and other pertinent information).

There is already room for that sort of thing in the stream_gpointer
field of STREAM.

> I am still working on this, but interfacing to the streams will be
> sic_printf(Sic *sic,...), sic_flushout(Sic *sic) and other access
> methods as needbe.

Cool.

> I did this to allow me to rip the guts out of the stream handling once
> I figure out what is really needed. 
> 
> I am still trying to get the basic functionallity working before
> getting back to redir. What I am finding is that we might need to
> flush stdout before forking in dollar.c and unknown.c - otherwise the
> state of stdout is indeterminate - and we get repeats in the output
> stream. (this only shows up in non-interactive mode during the tests
> because stdout is unbuffered).
> 
> When I have an initial version working, I will submit a patch for
> review.

Excellent.  Thanks again Ezra.

Gary.

-- 
  ___              _   ___   __              _         mailto: gv...@te...
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       ga...@gn... 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \      
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc