[GRASS-dev] Re: diff to start wingrass with GUI + com.exe terminal [was: Re: [winGRASS] (no subject)]

GRASS GIS GRASS GIS developer
1

Hello Moritz
(Cc grass-dev; sorry I'm not subscribed to the wingrass list)

On Mon, 21 May 2007, Moritz Lennert wrote:

On 21/05/07 02:27, Moritz Lennert wrote:

Paul,

The attached diff makes it possible to launch GRASS in GUI mode with an
accessible cmd.exe window by simply clicking on grass63.bat.

This makes winGRASS look a bit more like *nix GRASS in that it allows
access to both the GUI and the command line at the same time. Until now,
the only way to get this was to launch GRASS in text mode from the cmd.exe
command line.

Anything against me committing this ?

Just after shutting down my computer I realised that this probably only works on my machine because I have msys installed and the msys lib&bin in my path, so it probably is not a generalisable idea... Will have to try tonight when I'm in front of a Win machine again.

Yes launching gis.m using the "gis.m" shell script depends on having a shell interpreter - that's why init.bat runs "gm.tcl" directly.

But it wouldn't be too hard to re-arrange init.bat to have a command-line GRASS session also open when the GUI was running. At the minute there's a redundant cmd.exe Window running in the background anyway, but I was hoping to hide it. The idea being you really don't need it and I thought it was a bit messy they way it stays open when you're running Init.sh rather than init.bat.

But, I suppose maybe it would be a gentle introduction to command-line GRASS for Windows users if the other Window was open in the background and they were able to use it. It would complicate things though, as they would have to type exit in the command-line Window to exit it *after* shutting down gis.m; I worry that it would make GRASS look cumbersome and awkward. Was thinking perhaps an option button in gis_set.tcl (the first Tcl/Tk window that allows you to select the location) to open either GUI or Command-line Windows or both might be a nice idea?

I was going by the thinking that it was a historical accident that GUI and command-line were available at the same time with Init.sh, and with improvements to the GUI it would eventually incorporate a sort of command-line interface (like an improved gronsole.tcl) and a separate command-line Window wouldn't be necessary, but if we feel that it's good to have it there to emphasis the power of GRASS then we can definitely put it into init.bat too.

Paul

2

On 21/05/07 12:40, Paul Kelly wrote:

Hello Moritz
(Cc grass-dev; sorry I'm not subscribed to the wingrass list)

On Mon, 21 May 2007, Moritz Lennert wrote:

On 21/05/07 02:27, Moritz Lennert wrote:

Paul,

The attached diff makes it possible to launch GRASS in GUI mode with an
accessible cmd.exe window by simply clicking on grass63.bat.

This makes winGRASS look a bit more like *nix GRASS in that it allows
access to both the GUI and the command line at the same time. Until now,
the only way to get this was to launch GRASS in text mode from the cmd.exe
command line.

Anything against me committing this ?

Just after shutting down my computer I realised that this probably only works on my machine because I have msys installed and the msys lib&bin in my path, so it probably is not a generalisable idea... Will have to try tonight when I'm in front of a Win machine again.

Yes launching gis.m using the "gis.m" shell script depends on having a shell interpreter - that's why init.bat runs "gm.tcl" directly.

But it wouldn't be too hard to re-arrange init.bat to have a command-line GRASS session also open when the GUI was running. At the minute there's a redundant cmd.exe Window running in the background anyway, but I was hoping to hide it. The idea being you really don't need it and I thought it was a bit messy they way it stays open when you're running Init.sh rather than init.bat.

When running init.bat it also remains open, but not "accessible". Just sits in the background.

But, I suppose maybe it would be a gentle introduction to command-line GRASS for Windows users if the other Window was open in the background and they were able to use it. It would complicate things though, as they would have to type exit in the command-line Window to exit it *after* shutting down gis.m;

Actually, even if you type exit, the command line windows "waits" for the GUI to terminate before it closes.

I worry that it would make GRASS look cumbersome and awkward. Was thinking perhaps an option button in gis_set.tcl (the first Tcl/Tk window that allows you to select the location) to open either GUI or Command-line Windows or both might be a nice idea?

Yes, maybe that would be better, or even an option in the GUI to launch a command-line window...

I was going by the thinking that it was a historical accident that GUI and command-line were available at the same time with Init.sh, and with improvements to the GUI it would eventually incorporate a sort of command-line interface (like an improved gronsole.tcl)

I think we will have to wait for wxgrass to get a serious integrated CLI...until then for me a separate CLI is a must.

and a separate command-line Window wouldn't be necessary, but if we feel that it's good to have it there to emphasis the power of GRASS then we can definitely put it into init.bat too.

I personally like the combination because it allows easy scripting (e.g. looping) while still giving the "comfort" of the GUI. But maybe it is better to leave as is, i.e. if you want the combination, you have to launch GRASS in text version, make sure msys or another shell is in your path and then launch gis.m. Assuming that those who are comfortable using the command line are also comfortable doing the extra installation steps.

Moritz

3

Paul Kelly wrote:

But, I suppose maybe it would be a gentle introduction to command-line
GRASS for Windows users if the other Window was open in the background
and they were able to use it. It would complicate things though, as
they would have to type exit in the command-line Window to exit it
*after* shutting down gis.m; I worry that it would make GRASS look
cumbersome and awkward.

I agree, either launch the GUI or text mode, not both. But allow
starting the GUI from text mode if the user wants that, or vice versa.

Was thinking perhaps an option button in gis_set.tcl (the first Tcl/Tk
window that allows you to select the location) to open either GUI or
Command-line Windows or both might be a nice idea?

How about a menu item to open a terminal in the main File-> or Config->
menus? Or a button on the GIS Manager toolbar? (of course "-text" on
startup would get you there without the GUI as well)

I was going by the thinking that it was a historical accident that GUI
and command-line were available at the same time with Init.sh, and
with improvements to the GUI it would eventually incorporate a sort
of command-line interface (like an improved gronsole.tcl) and a
separate command-line Window wouldn't be necessary, but if we feel
that it's good to have it there to emphasis the power of GRASS then
we can definitely put it into init.bat too.

As you hint to, support is already (sort of) there in a non-obvious way
from gronsole.tcl, just type any shell command in the bottom part of the
"Output - GIS.m" window and click [Run]. Maybe it just needs some
tidying and a GRASS> prompt or something? Or is that always going to
suck badly versus a true <xterm|cmd.exe> window?
Does this start to violate concurrent mapset use?

Hamish

4

On 21/05/07 13:55, Hamish wrote:

Paul Kelly wrote:

I was going by the thinking that it was a historical accident that GUI
and command-line were available at the same time with Init.sh, and
with improvements to the GUI it would eventually incorporate a sort
of command-line interface (like an improved gronsole.tcl) and a
separate command-line Window wouldn't be necessary, but if we feel
that it's good to have it there to emphasis the power of GRASS then
we can definitely put it into init.bat too.

As you hint to, support is already (sort of) there in a non-obvious way
from gronsole.tcl, just type any shell command in the bottom part of the
"Output - GIS.m" window and click [Run]. Maybe it just needs some
tidying and a GRASS> prompt or something? Or is that always going to
suck badly versus a true <xterm|cmd.exe> window?

As long as it lacks any programming elements, such as loops and if/then I would say, yes.
Just the possibility of typing a GRASS command does not replace all the wealth of a shell.

Does this start to violate concurrent mapset use?

How ?

Moritz

5

On 5/21/07 4:38 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

I think we will have to wait for wxgrass to get a serious integrated
CLI...until then for me a separate CLI is a must.

Currently, there is a CLI where you can type any GRASS command (except a d.*
command) or any shell command and get the result in the output window.

d.* commands are currently blocked because they need to be processed into
the display canvas. That was working, but was broken in updates this year.
Needs to be fixed.

AFAIK, interactive shell commands do not work. This would require a full
terminal. This could be done, but there are pros and cons to doing so.

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

Michael

__________________________________________
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

6

Michael Barton wrote:

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

As I see it:

1. history
2. ability to set/unset variables
3. ability to put several commands into one line (eg. each separated
with ";")
4. tab-completion, for commands at least

Maciek

7

Thanks. This is a useful list. Some is already implemented but could be
improved.

Michael

On 5/21/07 10:31 AM, "Maciej Sieczka" <tutey@o2.pl> wrote:

Michael Barton wrote:

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

As I see it:

1. history
2. ability to set/unset variables
3. ability to put several commands into one line (eg. each separated
with ";")
4. tab-completion, for commands at least

Maciek

__________________________________________
Michael Barton, Professor of Anthropology
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

8

On Mon, May 21, 2007 17:23, Michael Barton wrote:

On 5/21/07 4:38 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

I think we will have to wait for wxgrass to get a serious integrated
CLI...until then for me a separate CLI is a must.

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

Scripting, i.e. a certain level of programming instructions which allow
you to combine different grass commands with other shell commands.
Something which when it becomes really ripe and useful can become a grass
script à la d.vect.thematic, but which many people just homecook to use
for their own convenience.

Moritz

9

On Mon, 21 May 2007, Hamish wrote:

Was thinking perhaps an option button in gis_set.tcl (the first Tcl/Tk
window that allows you to select the location) to open either GUI or
Command-line Windows or both might be a nice idea?

How about a menu item to open a terminal in the main File-> or Config->
menus? Or a button on the GIS Manager toolbar? (of course "-text" on
startup would get you there without the GUI as well)

I think that is more complicated than it needs to be. The GUI needs to know what the user's preferred terminal emulator is and have separate code for Unix and Windows etc. I was thinking perhaps a tick box in gis_set.tcl to say either "GUI only" or "GUI + command-line Window" could influence the return value gis_set.tcl returns to Init.sh. Then it could decided whether to either
(1) spawn gis.m in the background and to open an interactive GRASS prompt, or
(2) to just launch gis.m and block while waiting for the user to exit using File-->Exit
(1) is what Init.sh currently does, (2) is what init.bat currently does. Would be nice if both of them had the choice. It would just be one extra checkbox to be added to gis_set.tcl. Might be a nice hint (especially to Windows users) too that there is a more powerful command line interface available, to tempt them after they get comfortable with the GUI.

And if a user wants only command-line and no GUI there is still
"grass63 -text" for that, which avoids gis_set.tcl. And works with both Init.sh and init.bat.

I was going by the thinking that it was a historical accident that GUI
and command-line were available at the same time with Init.sh, and
with improvements to the GUI it would eventually incorporate a sort
of command-line interface (like an improved gronsole.tcl) and a
separate command-line Window wouldn't be necessary, but if we feel
that it's good to have it there to emphasis the power of GRASS then
we can definitely put it into init.bat too.

As you hint to, support is already (sort of) there in a non-obvious way
from gronsole.tcl, just type any shell command in the bottom part of the
"Output - GIS.m" window and click [Run]. Maybe it just needs some
tidying and a GRASS> prompt or something? Or is that always going to
suck badly versus a true <xterm|cmd.exe> window?

I think it would go some way towards making it adequate and might be enough for some users. My expectations of this are somewhat more modest than the lists Maciek and Moritz have proposed. Indeed history is already there - unfortunately commands already run are only selectable by scrolling back up and clicking with the mouse - perhaps it might be not much work to make the up arrow button also function for scrolling back through commands.

Redirection to a file is important for me too, rather than having to drag and copy and paste off the gronsole screen. Again, this might not be too hard to implement through Tcl because there is support there in the program launching commands to redirect stdout and stderr. And presumably this sort of thing is even easier with Python.

Also I wonder could it not be made that pressing Enter runs the currently highlighted command. Pressing enter currently brings you on to a new line in the text box which doesn't make sense to me?

Does this start to violate concurrent mapset use?

I don't think so - commands run from the menus and icons in the GUI show up in the gronsole.tcl Window the same way as commands run directly from the bottom panel so I don't think it's possible to run them concurrently.

Paul

10

On 5/21/07 12:52 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On Mon, May 21, 2007 17:23, Michael Barton wrote:

On 5/21/07 4:38 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

I think we will have to wait for wxgrass to get a serious integrated
CLI...until then for me a separate CLI is a must.

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

Scripting, i.e. a certain level of programming instructions which allow
you to combine different grass commands with other shell commands.
Something which when it becomes really ripe and useful can become a grass
script à la d.vect.thematic, but which many people just homecook to use
for their own convenience.

Currently from the CLI in gronsole you can run any script in CLI mode (i.e.,
typing all arguments from the CLI). In the wxgrass command line you can do
this and you can also just type the name of the GRASS script/command and
get the autogenerated dialog launched, just like you would from the
terminal.

AFAICT, you can do this for any bash or python script (or whatever the shell
can do something with).

Michael

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
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

11

On Mon, May 21, 2007 23:03, Michael Barton wrote:

On 5/21/07 12:52 PM, "Moritz Lennert" <mlennert@club.worldonline.be>
wrote:

On Mon, May 21, 2007 17:23, Michael Barton wrote:

Beyond an interactive terminal, what would a 'serious integrated CLI'
entail?

Scripting, i.e. a certain level of programming instructions which allow
you to combine different grass commands with other shell commands.
Something which when it becomes really ripe and useful can become a
grass
script à la d.vect.thematic, but which many people just homecook to use
for their own convenience.

Currently from the CLI in gronsole you can run any script in CLI mode
(i.e.,
typing all arguments from the CLI). In the wxgrass command line you can do
this and you can also just type the name of the GRASS script/command and
get the autogenerated dialog launched, just like you would from the
terminal.

AFAICT, you can do this for any bash or python script (or whatever the
shell
can do something with).

Yes, if you have a preexisting script. But you cannot type and run
something like (nonesense script for demonstration):

for val, col in $valnames
do
  d.vect map=X fcolor=$col cat=$val
done

You would have to save it as a script in your PATH and then launch it as
such.

Moritz

12

On 5/21/07 2:34 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

AFAICT, you can do this for any bash or python script (or whatever the
shell
can do something with).

Yes, if you have a preexisting script. But you cannot type and run
something like (nonesense script for demonstration):

for val, col in $valnames
do
  d.vect map=X fcolor=$col cat=$val
done

You would have to save it as a script in your PATH and then launch it as
such.

I know that you can do this with Python. But can you do it with a normal
bash terminal and shell scripting? I thought you are limited to what you can
do on one line.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
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

13

Michael Barton wrote:

>> AFAICT, you can do this for any bash or python script (or whatever the
>> shell
>> can do something with).
>>
>
> Yes, if you have a preexisting script. But you cannot type and run
> something like (nonesense script for demonstration):
>
> for val, col in $valnames
> do
> d.vect map=X fcolor=$col cat=$val
> done
>
> You would have to save it as a script in your PATH and then launch it as
> such.

I know that you can do this with Python. But can you do it with a normal
bash terminal and shell scripting? I thought you are limited to what you can
do on one line.

Bourne shells know when they have "incomplete" input (e.g. do/if/case
without a matching done/fi/esac, unmatched quotes, parentheses, etc),
and will keep prompting (using $PS2) for more input until they have a
complete command.

IIRC, C shells are more restrictive, e.g. you can't use loops (etc)
interactively, only in scripts.

--
Glynn Clements <glynn@gclements.plus.com>

14

Paul Kelly wrote:

(2) to just launch gis.m and block while waiting for the user to
exit using File-->Exit

hack:
remove the "&" in the gis.m script (or unset BG_GUI="&" and put $BG_GUI
at the end of the exec "$GRASS_WISH" lines).
Then start gis.m with "exec gis.m" and minimize/hide the cmd window
somehow.

I don't like the idea much of trying to reinvent a Full terminal prompt.
Seems to me we could spend a lot of time on that to recreate what
already exists, poorly. Keep it simple or use something already written.
Having said that, the GRASS terminal prompt from QGIS's GRASS toolbox
looks quite nice.

Glynn:

Personally, I would favour switching to Python.

If we forget about MSys C:/> path pain for a minute, and assume the
GRASS terminal will not be exposed to the user by default, does it
really matter if the backend interpreter to a script is Python or some
flavour of sh?

Is a full python interpreter needed for the wxPython GUI? (so we can
rely on python already being there?)

Tcl/Tk is still optional. With Python replacing sh for housekeeping
scripts, Python would become mandatory.

If we require Python to be installed, can the compiled SWIG library be
used without additional dependencies? (ie is the swig package only
needed at compile time?) Access to libgis fns opens up other doors.

import python_grass6
path=python_grass6.G_gisbase()
python_grass6.G_convert_dirseps_to_host(path)

?

Hamish

15

On 5/22/07 12:35 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Paul Kelly wrote:

(2) to just launch gis.m and block while waiting for the user to
exit using File-->Exit

hack:
remove the "&" in the gis.m script (or unset BG_GUI="&" and put $BG_GUI
at the end of the exec "$GRASS_WISH" lines).
Then start gis.m with "exec gis.m" and minimize/hide the cmd window
somehow.

I don't like the idea much of trying to reinvent a Full terminal prompt.
Seems to me we could spend a lot of time on that to recreate what
already exists, poorly. Keep it simple or use something already written.

Agreed. Or improve on what is already there in simple ways.

Having said that, the GRASS terminal prompt from QGIS's GRASS toolbox
looks quite nice.

Glynn:

Personally, I would favour switching to Python.

If we forget about MSys C:/> path pain for a minute, and assume the
GRASS terminal will not be exposed to the user by default, does it
really matter if the backend interpreter to a script is Python or some
flavour of sh?

Is a full python interpreter needed for the wxPython GUI? (so we can
rely on python already being there?)

AFAICT, you need full Python (or at least a runtime version) to use
wxPython. So assuming that we continue down this road, Python in some form
will become a dependency of the GUI at least.

Tcl/Tk is still optional. With Python replacing sh for housekeeping
scripts, Python would become mandatory.

If we require Python to be installed, can the compiled SWIG library be
used without additional dependencies? (ie is the swig package only
needed at compile time?) Access to libgis fns opens up other doors.

import python_grass6
path=python_grass6.G_gisbase()
python_grass6.G_convert_dirseps_to_host(path)

This is a fairly big decision I guess. But having worked with Python now for
9 months, it is one that I favor too. It is not an onerous dependency and
one that makes for much more flexible scripting plus real cross-platform
support.

Michael

__________________________________________
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

16

Hamish wrote:

Glynn:
> Personally, I would favour switching to Python.

If we forget about MSys C:/> path pain for a minute, and assume the
GRASS terminal will not be exposed to the user by default, does it
really matter if the backend interpreter to a script is Python or some
flavour of sh?

The main advantages of Python over Bourne shell are:

1. Python is more portable.

Windows ports of bash (etc) try to maintain compatibility with Unix at
the expense of compatibility with the system on which they are
actually running. Also, shell scripts typically require various
additional programs for functionality which is missing from the shell
(sed, awk, etc).

2. Python is a substantially better programming language.

Historically, the use of the Bourne shell has been for the sole reason
that it is always available. But that's only true on Unix. Once it
loses that that advantage, it has nothing else in its favour.

Is a full python interpreter needed for the wxPython GUI? (so we can
rely on python already being there?)

Tcl/Tk is still optional. With Python replacing sh for housekeeping
scripts, Python would become mandatory.

As it stands, a Bourne shell is mandatory, as are all of the utilities
which the scripts require.

Also, bear in mind that a GUI (and thus the language in which it is
written) is likely to become rather less optional in 7.x when the
interactive functionality is removed from the display architecture.

--
Glynn Clements <glynn@gclements.plus.com>