Re: [GRASS-dev] d.rast.edit in wxgrass

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [GRASS-dev] d.rast.edit in wxgrass

Michael Barton



On 6/14/07 12:28 PM, "Glynn Clements" <[hidden email]> wrote:

>> GRASS command parsing from the wxgrass CLI:
>>
>> Split the command into a list by spaces. I realize that this is a problem
>> for any command with spaces in the arguments, but I know of no better way to
>> do this in this context outside of making users type any command as a Python
>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of
>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
>
> This is one case where shell=True *is* legitimate. At least with a
> shell, the user can use quotes or backslashes to include spaces in
> arguments. Or you could implement equivalent functionality yourself.

IIUC, if I keep these as strings, I don't think I can use the cmd.Command
class and would have to do a custom version of Popen. Then I'd have to send
them through a different processing path rather than the RunCmd method that
everything else uses.

Michael

>
> The latter is more work, but you can choose exactly which shell
> functionality you want, e.g. allowing spaces (and other
> metacharacters) without the other shell behaviour (sequences,
> pipelines, redirection, variables, ....).

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

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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] d.rast.edit in wxgrass

Glynn Clements

Michael Barton wrote:

> >> GRASS command parsing from the wxgrass CLI:
> >>
> >> Split the command into a list by spaces. I realize that this is a problem
> >> for any command with spaces in the arguments, but I know of no better way to
> >> do this in this context outside of making users type any command as a Python
> >> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead of
> >> g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
> >
> > This is one case where shell=True *is* legitimate. At least with a
> > shell, the user can use quotes or backslashes to include spaces in
> > arguments. Or you could implement equivalent functionality yourself.
>
> IIUC, if I keep these as strings, I don't think I can use the cmd.Command
> class and would have to do a custom version of Popen. Then I'd have to send
> them through a different processing path rather than the RunCmd method that
> everything else uses.

One option is to call the shell explicitly, i.e.:

        cmd.Command(['/bin/sh', '-c', cmdstr], ....)

or (on Windows):

        cmd.Command(['cmd', '/c', cmdstr], ...)

Simply adding quoting to the existing implementation would probably be
preferable, though.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] d.rast.edit in wxgrass

Michael Barton
Martin,

Is this change in cmd.Command easy to implement?

Michael


On 6/15/07 9:09 AM, "Glynn Clements" <[hidden email]> wrote:

>
> Michael Barton wrote:
>
>>>> GRASS command parsing from the wxgrass CLI:
>>>>
>>>> Split the command into a list by spaces. I realize that this is a problem
>>>> for any command with spaces in the arguments, but I know of no better way
>>>> to
>>>> do this in this context outside of making users type any command as a
>>>> Python
>>>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead
>>>> of
>>>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
>>>
>>> This is one case where shell=True *is* legitimate. At least with a
>>> shell, the user can use quotes or backslashes to include spaces in
>>> arguments. Or you could implement equivalent functionality yourself.
>>
>> IIUC, if I keep these as strings, I don't think I can use the cmd.Command
>> class and would have to do a custom version of Popen. Then I'd have to send
>> them through a different processing path rather than the RunCmd method that
>> everything else uses.
>
> One option is to call the shell explicitly, i.e.:
>
> cmd.Command(['/bin/sh', '-c', cmdstr], ....)
>
> or (on Windows):
>
> cmd.Command(['cmd', '/c', cmdstr], ...)
>
> Simply adding quoting to the existing implementation would probably be
> preferable, though.

__________________________________________
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


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: Re: [GRASS-dev] d.rast.edit in wxgrass

Glynn Clements

Michael Barton wrote:

> >>>> GRASS command parsing from the wxgrass CLI:
> >>>>
> >>>> Split the command into a list by spaces. I realize that this is a problem
> >>>> for any command with spaces in the arguments, but I know of no better way
> >>>> to
> >>>> do this in this context outside of making users type any command as a
> >>>> Python
> >>>> list. If we made people type ['g.region', 'rast=mymap', 'res=30'] instead
> >>>> of
> >>>> g.region rast=mymap res=30, I don't think anyone would want to use the CLI.
> >>>
> >>> This is one case where shell=True *is* legitimate. At least with a
> >>> shell, the user can use quotes or backslashes to include spaces in
> >>> arguments. Or you could implement equivalent functionality yourself.
> >>
> >> IIUC, if I keep these as strings, I don't think I can use the cmd.Command
> >> class and would have to do a custom version of Popen. Then I'd have to send
> >> them through a different processing path rather than the RunCmd method that
> >> everything else uses.
> >
> > One option is to call the shell explicitly, i.e.:
> >
> > cmd.Command(['/bin/sh', '-c', cmdstr], ....)
> >
> > or (on Windows):
> >
> > cmd.Command(['cmd', '/c', cmdstr], ...)
> >
> > Simply adding quoting to the existing implementation would probably be
> > preferable, though.
>
> Martin,
>
> Is this change in cmd.Command easy to implement?

The above isn't a change to cmd.Command(), but a change to how it is
used.

If you were to change cmd.Command(), the obvious change would be to
add a shell= parameter, which would be propagated directly to Popen().

Ultimately, if all you have is a single string provided by the user,
that string somehow has to be converted to a list of strings (as
that's what argv[] is).

The options are:

1. Split at each space.
2. As for 1, but with a quoting and/or escaping mechanism.
3. Use the shell.

1 fails to handle arguments which contain spaces. 2 solves this, but
requires some work. 3 gets the shell to do the work, but the cost is
that you get a lot of other stuff which you may not want
(substitution, redirection, loops, subshells, ...).

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui