Hello everyone
On Thu, 1 Nov 2007, Moritz Lennert wrote:
On Wed, October 31, 2007 11:29, Benjamin Ducke wrote:
The start command does actually work to put gis.m in the background.
I changed init.bat to read:
I propose to do it in this (slightly modified) way:
In init.bat:
===
rem Get LOCATION_NAME to use in prompt
FOR /F "usebackq delims==" %%i IN (`g.gisenv "get=LOCATION_NAME"`) DO @set
LOCATION_NAME=%%i
cd %HOME%
prompt GRASS %GRASS_VERSION% $C%LOCATION_NAME%$F:$P $G
start "GRASS %GRASS_VERSION% Shell" cmd.exe /E:ON /F:ON /V:ON
%WINGISBASE%\bin\gis.m.bat
===
I'm trying to follow what's going on here but it's bit confusing - would
help if somebody posted a diff of the proposed changes to init.bat (the
usual way). Have a few comments anyway about my original philosophy of why
init.bat does things the way it does, which hopefully might help clarify
things.
There is not supposed to be a command-prompt running separately from that
included in gis.m - I thought we were moving towards the idea of having a
command prompt built into the gronsole Window and using that (I think it's
improved further in wxgrass) - so that was the point of that. I think it
is confusing for new users having to type exit in a command Window to
totally exit GRASS as well as just going File-->Exit in the GUI menus (is
that what's being proposed here?).
If somebody wants a GUI and console then I think it's OK to require them
to start GRASS in text mode and run gis.m from the command prompt. So I
actually think Moritz's new gis.m.bat is a really good idea. I just was
too lazy to get round to implementing that before. And there was some
complication about the way the gis.m Shell script was generated although I
think I simplified things a little bit.
Also I'm not sure what the "cd %HOME%" is for. GRASS on Unix doesn't
change the directory you were in before starting it AFAIK - why should it
on Windows? And how important is the "/E:ON /F:ON /V:ON"? I just want to
be sure we're not introducing anything that doesn't *need* to be there and
is only likely to confuse people in years to come.
where gis.m.bat simply contains:
===
@ start "GIS Manager" "%GRASS_WISH%" "%WINGISBASE%/etc/gm/gm.tcl"
===
This way we have a functioning gis.m.bat which one can also launch from
the command line if grass was started with in text mode.
That's a good idea. ISTR that the gis.m shell script now also runs gis.m
in the background, i.e. you don't need to run it as "gis.m &" any more -
is that right?
We'd need to make sure GRASS_WISH is always set though. Currently init.bat
doesn't require it to be set and will use Window's association of .tcl
files with the Tcl interpreter to start gis.m correctly if not. But I
don't think it's unreasonable to require GRASS_WISH to always be set and
we could change that.
Nice also to finally get rid of this empty and useless cmd.exe window we
had before.
Do you mean with the changes the init.bat script is exiting/abandoning
after starting gis.m? The whole point of it staying running (and as a
side-effect keeping a command prompt Window open - I don't know how to
hide that but I presume it's possible) is because there are actions that
run as part of exiting GRASS - the main one being deleting temporary
files, but also setting the PATH back to its original value if a
command-line session was being run. If we exit init.bat after starting
gis.m then the temporary files won't be deleted on exit which I don't
think is a good idea.
Only thing which is a bit annoying: you have to close the two (cmd and
gis.m) seperately (i.e. gis.m does not close when you type exit in
cmd.exe). But that's minor in my eyes.
Users who don't normally use the command line may not know to type exit -
I think it's a big enough issue not to introduce it as a problem when it
wasn't there before - see my comments above.
One question I don't know how to solve, though: just as for other scripts
a gis.m.bat is created during compilation, which contains:
@"%GRASS_SH%" -c '"%GISBASE%/scripts/gis.m" %*'
However, I think that gis.m should run independently of whether someone
has installed a shell, so I'd rather replace this bat file by the one
above. This would mean creating some form of exception for gis.m to the
below entry in include/Make/Script.make:
It was my idea for a while (never implemented it though) that the Script
Makefile could look and see if there was a "Windows version" (i.e. the
script name with a .bat extension) in the same directory, and if so
install it rather than installing a wrapper to the Bourne shell version of
the script. Would that perhaps be useful here if we got it working?
BTW sorry I've been so inactive in the discussions recently. I had very
limited internet access for a much longer period than anticipated over the
past month and a half, but have a regular connection again so should
hopefully be able to contribute a bit more now. Have quite a backlog of
other stuff to get through though.
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
