[GRASS-dev] Some questions about standardization

Hamish hamish_nospam at yahoo.com
Sun Jul 8 03:39:05 EDT 2007


Carlos Dávila wrote:
> I would like to get some feedback about the changes I'm doing to
> standardize. As some questions in the air do not get answers I'm
> following what is in wiki, but I wouldn't like to bother anyone with
> the changes.
> 
> I need some help to continue with further changes. As I'm not
> programmer I don't know well what can be changed in code and what
> can't, so I ask you some cases:
> a) %s: can't open tempfile -> Unable to open temporary file <%s> (does
> it affect where is the %s?)

The meaning of the string matters, I suspect the first %s string is the
program name, and the second is the filename. So just moving it is wrong
for meaning but ok for C syntax.

FWIW, the program name will be mostly redundant unless it is a module
mainly used as a scripting tool (for example g.*). And giving the exact
name of a non-existant tmp file does not help the user much, the main
point is that they couldn't write to $MAPSET/.tmp/$HOST/<>. (e.g. mapset
copied from read-only CD-ROM without resetting permissions or user name)
It may be more useful to know that if Paul moves some tmp file creation
into /tmp/, but for now, in my 2c opinion, it is just minorly-helpful
noise.

> b) can't open raster map <%s> in mapset %s -> Unable to open raster
> map <%s> (Can I drop last %s without problems?)

not without changing the variables passed to G_fatal_error()

> c) How can I pass from "Unable to open the temporary file." to "Unable
> to open temporary file <%s>"? E.g. from
> /display/d.text.freetype/main.c:
> 
> tmpfile = G_tempfile();
>         if(!(fp = fopen(tmpfile, "w")))
>             error(_("Unable to write the temporary file"));

(don't bother to spend much effort on d.text.freetype, it is scheduled for
oblivion)

but,

G_fatal_error(_("Unable to write the temporary file <%s>"), tmpfile);


Hamish


ps - I just added this to the wiki and reverted associated changes in
v.to.rast and g.list. http://grass.gdf-hannover.de/wiki/Development_Specs

*  Only user derived variables should be bracketed, not GRASS derived
variables. for example: 

Yes: Creating raster map <%s>.  Pass 1 of 7 ...
No:  Creating <raster> map <%s>.  Pass [1] of [7] ...


Hope everyone agrees, discussion on the grass-dev ML is preferable, as the
wiki reflects the opinion of the last editor, not == to the group consensus.


pps- also added on the wiki:
("Cannot find input map <%s>" instead of "It could not be find input map
<%s>")

Added: avoid the issue altogether by rewording "possibly better:
 "Input map <%s> not found."





More information about the grass-dev mailing list