[GRASS-dev] GRASS startup screen patches && Gforge

Glynn Clements glynn at gclements.plus.com
Sun Jan 21 20:07:42 EST 2007


Wolf Bergehneim wrote:

> > Just makes small improvements to startup screen. Like preselects newly
> > created mapset/location, disables mapset creation in invalid locations
> > etc. Full change list at GF.
> > 
> > http://wald.intevation.org/tracker/index.php?func=detail&aid=263&group_id=21&atid=205 
> > 
> > This one is a bit more discussion worth. It adds restrictions on
> > creating new location/mapset from startup screen to allow only Latin
> > letters and numbers, "-" and "_" symbols in loc/ms name.
> 
> 
> > 1) Allowed symbol list can be easily extended. But allowed symbols
> > should be allowed in *nix/Mac/Win on all common file systems in
> > directory names;
> 
> Uhumm... Currently I use mapsets that also include dots "." As in 
> Maa-123.450, and this has worked so far, and I'd wish for it to remain 
> the same.

Dots shouldn't pose any problems.

We shouldn't impose restrictions because some operating systems might
not allow the filename. In particular, Windows has some strange
restrictions as to what isn't permitted, e.g. you can't create a file
or directory whose name (minus any extensions) matches the name of a
device (e.g. "con" or "aux").

The only prohibited characters should be those which we know will be
problematic for GRASS itself, e.g. = or , (which are G_parser()
syntax), spaces (in "internal" file or directory names; we need to
allow for them in $HOME, $TEMP, $PATH, GISDBASE etc), certain control
characters (primarily newline; note that the ESC character may occur
in ISO-2022 filenames).

> > 2) Restriction to have at least one letter in name IMHO is just sane;
> 
> I'm not so sure about that. someone might want to name a region to the 
> current grid name, which could be a number, would make a lot of sense to 
> me to allow numeric only names, in everything, that is vectors, rasters, 
> locations, mapsets, etc.

Agreed.

However, vectors are problematic because vector map names can be used
directly as SQL table names, so they have to begin with a letter or
underscore. Personally, I don't consider this acceptable, but I don't
understand the vector system well enough to change it.

> > 3) Currently GRASS can NOT handle any other letter except Latin on
> > multi byte locales. As uni byte locales must die (except those, with
> > plain Latin letters only) as they are only source of problems and
> > nothing else (I have files with Latvian/Russian/German names in one
> > folder - UTF is a must). Till GRASS start support multi byte locales,
> > it's sane restriction. Till that happens, I can only say: "-LХюстон, у-A
> > -Lнас проблема" (I hope, I spelled it right ;)-A
> 
> I agree UTF support is a must! I think that UTF support should be 
> something we want to have ASAP. I don't know how much work it would be 
> to support UTF-8, but I don't believe that it would be very much.

For the core functionality, it should just be an issue of extending
G_legal_filename() to allow all bytes in the range 128-255 in map
names.

Specific subsystems may have problems, e.g. curses cannot handle
multi-byte encodings. Also, I don't know how well the various database
back-ends cope, but that's largely beyond our control.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list