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

[Maris Nartiss]

Hi Wolf, Glynn.

Thanks for Your answers.
First - let's get done with restrictions to location/mapset names and
then move to raster/vector map names, as they are more complex than
loc/ms restrictions.
My comments inline.

2007/1/22, Glynn Clements <glynn at gclements.plus.com>:
>
> 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.
You both are right. I forgot about dots. Only exception - they should
be banned from first place (".foo") as file/directory starting with .
is hidden in *nixes.

>
> 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").
This is discutable.
1) Some GRASS parts are written in optimistic way - i.e. no checks on
mkdir call returns codes etc. I added some checks to startup screen,
but it may be not only place with following bad coding practice. Those
are bugs and need to be fixed.
2) Maybee we could add some OS specific name restrictions in GUI? User
errors must be catched as fast as possible to provide good user
expierience. *

>
> 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.
My fault. I was thinking one step farther.

There was already note, that pure numbers may be problematic in map
names as in some cases they may be threated as numbers and not map
names. It's possible to include such map names in "" in mapcalc. Any
other place where numbers may be misinterpreted?

If there is no place where location/mapset name may be confused with
something else (number)? If no, this restriction must be removed.

>
> 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.
Let's deal with loc/ms first, as they are not as problematic ;)

Any fundamental change in vector architecture, unfortunately, will
have to wait till 7.0 :(

>
> > > 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.
It may not be as easy as it sounds - I read some (a bit outdated?) doc
[1] and if I understood this part [2] correctly, we may need to check
~26'000 variables and they usage to make GRASS fully UTF-8 aware. As
minimum it requires to check ~1000 lines containing strlen().
Ofcourse, most of them have nothing to do with file names, but still
better would be not to brake something by accident ;)

>
> 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.
This is beyound my understanding. Sorry, no help from me. I can only
test Your code, as I'm on UTF-8 locale.

>
> Specific subsystems may have problems, e.g. curses cannot handle
> multi-byte encodings.
Ncurses since version 5.3 can handle UTF-8.
"The normal ncurses libraries support 8-bit characters. The ncurses
library can also be configured (--enable-widec) to support
wide-characters (for instance Unicode and the UTF-8 encoding). The
corresponding wide-character ncursesw libraries are source-compatible
with the normal applications. That is, applications must be compiled
and linked against the ncursesw library." [3]

> Also, I don't know how well the various database
> back-ends cope, but that's largely beyond our control.
Here we can't do anything except warning user about failure possibility.



Maris.

[1] http://www.debian.org/doc/manuals/intro-i18n/index.en.html
[2] http://www.debian.org/doc/manuals/intro-i18n/ch-locale.en.html
[3] http://dickey.his.com/ncurses/ncurses.faq.html


* Long time a go I was playing text based game in DOS named MAFIA. It
had one major flaw - no checks of user input. When I coosed to play
Russian rulette, I needed to enter amount of money and it was assigned
to float without cast. You can imagine what happened, if by accidend I
entered some letter there ;) Every time I see some programm not
checking user input before using it, I remember Mafia game and how it
sucked when segfaulted after hour of playing when I accedentaly
entered wrong symbol.