Martin wrote:
> so what's the preferred solution for G7
>
> 1) single variable GRASS_ADDON_PATH for all components
> (as it is)
> 2) two variables - GRASS_ADDON_BASE and
> GRASS_ADDON_PATH (path only as in G6)
Glynn:
#1. Although the name doesn't matter.
If the user wants to add extra executable directories,
they can modify PATH directly.
[moving this thread over to the dev list]
as per earlier email in this thread, from my POV option #2 is the preferred solution. Definitely change the name
away from PATH for usage which isn't $PATH anymore.
if it doesn't harm to automatically prepend the $PATH,
then why not make that easy for those who want to use it?
> Martin wrote:
> > so what's the preferred solution for G7
> >
> > 1) single variable GRASS_ADDON_PATH for all components
> > (as it is)
> > 2) two variables - GRASS_ADDON_BASE and
> > GRASS_ADDON_PATH (path only as in G6)
Glynn:
> #1. Although the name doesn't matter.
>
> If the user wants to add extra executable directories,
> they can modify PATH directly.
[moving this thread over to the dev list]
as per earlier email in this thread, from my POV option #2 is the preferred solution. Definitely change the name
away from PATH for usage which isn't $PATH anymore.
if it doesn't harm to automatically prepend the $PATH,
then why not make that easy for those who want to use it?
Because it's one more unnecessary environment variable. Some systems
have a limit (4k is common) on the combined memory used by the
environment and the command line, so enlarging the environment reduces
the maximum length of a command.
A single environment variable is sufficient to find all components of
an add-on. The original idea seems to have been based upon the
assumption that an add-on would consist of a single script, with no
additional files. That assumption should be false for anything from
the add-ons repository (there should at least be a manual page).
Because it's one more unnecessary environment variable.
Some systems have a limit (4k is common) on the
combined memory used by the environment and the command
line, so enlarging the environment reduces the maximum
length of a command.
fair enough. but,
A single environment variable is sufficient to find all
components of an add-on. The original idea seems to
have been based upon the assumption that an add-on
would consist of a single script, with no additional
files.
right.
That assumption should be false for anything from
the add-ons repository
as per longer explanation in a prior email, I'd argue
that the case of the single personal script with no
support files is still at least co-equal if not the
dominant instance for addon scripts.
we hear about g.extension disproportionally because it's
a tricky cross platform dance to get it working smoothly
and folks probably don't bother us much with errors in
their personal workflows.
Hello,
Choosing a map layer with the browser of any module appears a expresion like this:
mapName@en mapasDatasetName
adding ‘en mapas’ at the normal one mapName@DatasetName
So, after it can’t read it well and there is un error like ‘map no exists’.
Erasing ‘en mapas’ in the expresion, everything go well.
Working with last GRASS 6.4.2RC1 of georepository of openSuse11.3 in spanish.
single variable GRASS_ADDON_PATH for all components
(as it is)
two variables - GRASS_ADDON_BASE and
GRASS_ADDON_PATH (path only as in G6)
Glynn: #1. Although the name doesn’t matter.
If the user wants to add extra executable directories,
they can modify PATH directly.
[moving this thread over to the dev list]
as per earlier email in this thread, from my POV option #2 is the preferred solution. Definitely change the name
away from PATH for usage which isn’t $PATH anymore.
if it doesn’t harm to automatically prepend the $PATH,
then why not make that easy for those who want to use it?