[GRASS5] Parsing and other problems.

[Glynn Clements]

roger wrote:

> d.what.vect -- the terse output from d.what.vect contains no useful clue about
> where to define the end of data produced by a single query.  The output
> includes a line of whitespace prior at the beginning of a query result.  To
> make it possible to parse the output I moved that line of whitespace to the
> end of the data output and then flushed both stdout and stderr.  I think
> stdout was already being flushed, so it may only be flushing stderr that made
> any difference.

If anything, it's the other way around. stdout is line-buffered if the
underlying descriptor refers to a terminal, and block-buffered
otherwise (e.g. if it refers to a pipe). stderr is always unbuffered.

> d.what.rast, d.what.sites -- in both cases the script needed stderr redirected
> to stdout.  That isn't in itself a problem, but after the query process
> stopped (button 3 was pressed) both programs always repeated the last query
> result before closing.  That caused the last result to be produced twice, the
> second in response to pressing button 3.  To avoid the problem I had both
> programs flush both stdout and stderr after each query.
> 
> I would like to have the changes made in the distributed versions but I no
> longer keep a development installation -- just production -- so I don't want
> to introduce the changes to CVS myself.  The change to d.what.vect is minor
> but it does change the output in a way that conceivably could break someone
> else's scripts.  I don't know of any problem that might come up from the
> changes in d.what.rast or d.what.sites.  If there are no objections could
> someone else make those changes?  I can provide the modified code for someone
> who is willing to make the change.

Personally, I think that there should be three changes to d.what.rast:

1. The data written to stdout should be the same regardless of whether
or not it refers to a terminal, i.e. the isatty(fileno(stdout)) stuff
should go. If more formats are required, additional command-line flags
should be provided.

2. The data should only be written to stdout, not stderr.

3. There should be an fflush(stdout) after each operation, i.e. at the
bottom of the do-while loop in what.c.

> The Grass 5.3 source that I am using now includes Glynn's code for a d.info
> command.  The command was not compiled by default.  Is that intentional, or
> was it a problem with my compilation?

Intentional; sort of. If I write a new program, I don't usually
arrange for it to be compiled by default until others have commented
on it. Essentially, I don't want people to start relying upon it while
significant aspects of the behaviour are still up for discussion.

-- 
Glynn Clements <glynn.clements at virgin.net>