> However, the same doesn't work within the display manager with, for
> instance, d.vect. In that case, the 'where' parameter ends up within
> braces in the actual call.
Some more fiddling led me to find out the correct syntax in display
manager:
str_3='"W Arctic"'
which creates a valid sql query and the map plots correctly. However,
this runs into another problem with d.out.file from a display of the
queried map and says:
Sorry <Arctic'> is not a valid option
Could this be a bug? If the 'where' statement does its job with this
string, I would have expected d.out.file to work too.
I suspect that this is a bug in G_recreate_command().
On Sun, 25 Mar 2007 02:48:15 +0100,
Glynn Clements <glynn@gclements.plus.com> wrote:
[...]
I suspect that this is a bug in G_recreate_command().
What does "d.save -a" output?
This returns the following for the 'where' parameter:
where="str_3='"W Arctic"'"
exactly as it was entered in the display manager, which wouldn't work from
the command line or a script because the double quotes (within the single
quotes) are not escaped.
> I suspect that this is a bug in G_recreate_command().
> What does "d.save -a" output?
This returns the following for the 'where' parameter:
where="str_3='"W Arctic"'"
exactly as it was entered in the display manager, which wouldn't work from
the command line or a script because the double quotes (within the single
quotes) are not escaped.
By "display manager", are you referring to d.m or gis.m? d.m is
essentially obsolete; any non-trivial bugs are unlikely to get fixed.
OTOH, gis.m shouldn't require any additional quoting in most cases (in
a command layer, complex options should be enclosed entirely in
braces, e.g. "d.vect map {where=str_3 = 'W Arctic'}").
On Sun, 25 Mar 2007 03:59:45 +0100,
Glynn Clements <glynn@gclements.plus.com> wrote:
[...]
By "display manager", are you referring to d.m or gis.m? d.m is
essentially obsolete; any non-trivial bugs are unlikely to get fixed.
Indeed, I was doing this in d.m, and didn't find this problem with gis.m.
However, how do you tell d.save in gis.m what monitor to use? I have
gotten very used to x0-... kind of names, and I don't see these anymore in
gis.m. Thanks for your feedback.
> By "display manager", are you referring to d.m or gis.m? d.m is
> essentially obsolete; any non-trivial bugs are unlikely to get fixed.
Indeed, I was doing this in d.m, and didn't find this problem with gis.m.
However, how do you tell d.save in gis.m what monitor to use? I have
gotten very used to x0-... kind of names, and I don't see these anymore in
gis.m. Thanks for your feedback.
gis.m doesn't use monitors, so you can't use d.save on the gis.m displays.
In any case, there are several issues here.
One is the problem which d.m has with option values which contain
spaces, quotes or other characters which are significant to the shell.
I'm not sure that this is likely to get fixed; currently, d.m is
considered obsolete, gis.m is being maintained, and active development
is focusing on a new Python-based GUI.
The most significant issue is that G_recreate_command (which
reconstructs a command line) doesn't appear to handle shell characters
correctly. However, it *should* handle your where= case correctly. If
you run d.vect from the command line, "d.save -a" should show a valid
representation of the command.
Beyond that, it's possible that there is a problem which is specific
to d.out.file, although it's just evalutating the output from d.save.