[GRASSGUI] commands from menus and database table not working

[Michael Barton]

That's excellent. Should I update and try it?

Any thoughts on my locked up r.profile command??

Cheers
Michael


On 5/22/07 1:02 PM, "Daniel Calvelo" <dca.gis at gmail.com> wrote:

> Hi all.
> 
> grassTask is list-ready. In menuform.py, the grassTask.getCmd() is
> meant to return a list. We discussed this a few months ago. The
> quick'n'dirty way of maing this into a command string is to
> 
> " ".join( getCmd() )
> 
> This is used in e.g. building the statusbar "current command string",
> and used to be also in the OnCopy() event handler. wxgui.py and
> wxgui_utils.py should be changed to accomodate a list and call
> getCmd() directly instead of the join snippet or equivalent.
> 
> Daniel.
> 
> On 5/21/07, Glynn Clements <glynn at gclements.plus.com> wrote:
>> 
>> Michael Barton wrote:
>> 
>>>>     self.cmd_output.write("$ " + command + "\n")
>>>> TypeError: cannot concatenate 'str' and 'list' objects
>>>> 
>>>> Why:
>>> 
>>> The problem is not command but "$ " and "\n". They is a strings. Change to
>>> 
>>> ['$ '] + command + ['\n']
>> 
>> That will produce a list; does write() accept a list?
>> 
>> But the default string conversion performed by %s probably isn't what
>> you want. From the leading "$", I'm guessing that you want output in
>> shell syntax, which is going to need some form of quoting.
>> 
>> OTOH, you could just use Python syntax. Generating Bourne-shell syntax
>> is arguably wrong for something that's supposed to be cross-platform.
>> 
>>>> method getCmd() of grassTask() class (gui_modules/menform.py, line 215)
>>>> returns not command string (e.g. "r.info elevation.dem"), but already
>>>> command list (e.g. ["r.info", "map=elevation.dem"]).
>>>> 
>>>> This is in conflict with rest of the code, where ever cmd.split(" ") is
>>>> called (e.g. wxgui.py line 410 or gui_modules/wxgui_utils.py, line 868).
>>> 
>>> cmd.split(" ") is potentially problematic and we should avoid it. For
>>> example, <some command> map="My map" will end up as
>>> 
>>> ['<command>', 'map=My', 'map'].
>> 
>> It doesn't matter for maps, as spaces aren't valid in map names. But
>> it matters for arbitrary text (titles, etc), filenames, SQL "where"
>> clauses etc.
>> 
>>> Or <command> query="attribute1>5 and attribute2<15"
>>> 
>>> ['<command>', 'query=attribute>5', 'and', 'attribute2<15']
>>> 
>>>> 
>>>> So, what to do? Fix getCmd(), so it returns string or go through whole
>>>> code and try to fix all cmd.split() calls?
>>> 
>>> The latter. We've already got most of them, but there are a few left
>>> apparently.
>> 
>> What is the purpose of getCmd()? If it's meant to return the command
>> in a form that can be executed within wxgui, it should return a list.
>> 
>> If it's simply a string to show to the user, the format isn't
>> critical. OTOH, if it's going to be saved to a script, it needs to be
>> in the appropriate syntax (sh, csh, cmd.exe, etc).
>> 
>> The main point is that, if you have a function which returns a command
>> as a string, you need to be absolutely crystal clear on what syntax is
>> used. If it's Bourne-shell syntax, don't try to execute it via cmd.exe
>> (and vice-versa). If it's just "human-readable string", don't try to
>> execute it at all.
>> 
>> Depending upon what you want to do, you might need multiple functions
>> to return commands in different formats. In that case, I would suggest
>> having class methods always return commands as lists, and have
>> separate utility functions for converting such lists to strings.
>> 
>> --
>> Glynn Clements <glynn at gclements.plus.com>
>> 
>> _______________________________________________
>> grassgui mailing list
>> grassgui at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grassgui
>> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton