Perhaps an environmental variable like SQL_BROWSER_PATH might be
useful, given that the name (on my Mac at least) is full of spaces and
has an embedded version number which will change with every update.
Some kind of find that could return the name and path the the browser
could automate this.
I don't think anything new or fancy is needed-
SQLITE_BROWSER="`which sqlitebrowser`"
should be enough. If a path with a space in it doesn't work, then it is
a variable quoting bug which should be systematically fixed. The browser
executable needs to be in the $PATH, that isn't a big ask.
Worst case make a symlink to it in /usr/local/bin or $GISBASE/bin/.
I have several other randomly related thoughts.
1. If we do use sqlite, we need a translation utility between dbf and
sqlite.
db.copy?
dbview -bt -d '|' | v.in.ascii
(replace dbview utility with db.select?)
The long wished for db.in.ascii module?
2. We might want to have an "sql" directory in each mapset, like we do
for dbf.
Make that a "sqlite" dir, as "sql" is too generic to be meaningful.
This would be the location for a default sqlite database for
each mapset, containing tables for each vector file. The default
database could simple carry the name of the mapset. This does not
preclude the creation and use of other sqlite database in other
locations, of course. 3. GRASS would need to be able to create an
empty sqlite database automatically for each mapset, so that tables
could be added as needed.
Maybe I don't understand sqlite (never used it); why doesn't each map
have its own DB file in the first place? Why does there have to be a
single all-of-mapset one? I can't imagine the overhead per DB is that
huge.
The browser could actually live inside the GRASS directory structure
(e.g., $GISBASE/bin or somewhere else meaningful) if included, as it's
not all that big. In this case, it could be given a simple name like
"sqlite_browser". This might make the test you propose easier. It
could also be a link to the app in another location, but that might
get more difficult.
I think it is best left as an external (and optional?) dependency. I
sure don't want to maintain the thing or keep it in sync. The more we
can outsource to gdal, proj4, etc., the better I think. We've got enough
to work on as it is. It's the packagers' jobs to take care of making
sure those things get installed too...
Also, I would suggest we not make any decision about changing the
default DB to sqlite until after GRASS 6.2 is released.
Hamish
But this time I started using it!
But this time I started using it!