Hello Paul, On Thu, November 1, 2007 22:28, Paul Kelly wrote: > 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).
Yes, sorry. Here it is: --- grasssrc/grass6/lib/init/init.bat Thu Nov 1 22:32:29 2007 +++ init.bat.new Thu Nov 1 22:56:41 2007 @@ -95,13 +95,17 @@ rem This doesn't seem to work; don't understand return codes from gis_set.tcl P K rem if return ok, gis.m start: if %errorlevel% == 2 goto exitinit - -if not "%GRASS_WISH%"=="" ( - "%GRASS_WISH%" "%WINGISBASE%\etc\gm\gm.tcl" -) else ( - "%WINGISBASE%\etc\gm\gm.tcl" -) - + +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 + +%WINGISBASE%\bin\gis.m.bat + "%WINGISBASE%\etc\clean_temp" > NUL: goto exitinit > 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. Well, currently the gronsole command prompt is very limited, and so having access to a console still has its advantages. Current feedback from wingrass users shows that there are not only windows users afraid of anything which remotely looks like a command prompt, but also those users who are comfortable with grass on the command line in *nix and would like to (or have to) run grass on a windows machine. From Benjamin's suggestions I also had the feeling that there is a need for the console... But if we decide to leave the console for power users who can find out how to start grass in text mode and, if needed, launch gis.m from there, I'm fine with that as well. A new gis.m.bat as the one I proposed makes this easier. > 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?). It is. This is how it has been for users on other platforms for quite a while. Yes it is a bit confusing, but if we think that having a console is important it might be the lesser of evils. > 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. +1 Benjamin ? > And there was some > complication about the way the gis.m Shell script was generated although I > think I simplified things a little bit. Currently the gis.m.bat script is created via Script.Make, just as any other script. But it shouldn't as it is a special case where the script does not need sh.exe to be launched. This is why I'm looking for a way to treat gis.m differently from the other scripts. > 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? Because you don't start it from a command line, but by clicking on the grass63.bat file, and so it always starts in c:\grass\bin or wherever the .bat file resides. You can obviously change this behaviour when you make a shortcut which you put on your desktop and in the properties of which you can set a startup directory, but once again we're already at the level of a more advanced user here. To me starting in the %HOME% directory seems the most intuitive in a windows environment. > And how important is the "/E:ON /F:ON /V:ON"? For the record (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true): /e:on : Enables command extensions. [but only for a limited list of commands] /f:on : Enables file and directory name completion. /v:on : Enables delayed environment variable expansion. Probably not important at all and they can always be set by the user if they want to. Actually in XP /E is set on by default AFAICT. > 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? This is because in the gis.m script launches gm.tcl with the ampersand: exec "$GRASS_WISH" "$GISBASE/etc/gm/gm.tcl" -name gm_tcl & IIUC, this will not work in windows, however, and so we use the windows specific 'start' command. > > 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. Are you sure ? In init.bat, we currently have: if "%GRASS_WISH%"=="" set GRASS_WISH=wish.exe So unless someone explicitely unset GRASS_WISH, it will always be set. I've actually tried running gis.m with GRASS_WISH unset and it starts but crashes immediately because of the missing GRASS_WISH. This is probably due to: /c/grass/grass-6.3.cvs/etc/gm$ grep WISH * animate.tcl:# exec $GRASS_WISH "$0" "$@" gmmenu.tcl: {command {[G_msg "About &System"]} {} {[G_msg "About System"]} {} -command { exec $env(GRASS_WISH) $env(GISBASE)/etc/gm/tksys.tcl --tcltk & }} tksys.tcl:exec $GRASS_WISH "$0" "$@" > 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. Yes. I had forgotten about all that. So, we'll have to find another way. Just as a reminder: the problem is that windows automatically opens a cmd.exe window when you launch a .bat file. I think that unless you use some other programming language that calls this .bat file (instead of just clicking on it), this is unavoidable. But it is not so nice to have this "useless" cmd.exe window open all the time. Actually you can hide the window if you use a shortcut to grass63.bat. In its properties you can set it to "minimized". But again, this means more advanced user action than what we seem to aim at. We could maybe include a .lnk file in the distribution for which this is preset. Don't know how portable these binary .lnk files are... One option would be to use the start command in grass63.bat, such as: start /min cmd /c "%WINGISBASE%\etc\init.bat" %* It spawns a new minimized cmd.exe which then runs init.bat. This works great for GUI startup, but when you launch grass63.bat -text, you have the incovenience of a) another cmd window open for grass and b) you have to maximize the window to be able to enter grass. And since the 'text' option can come from the .grassrc6 file, we cannot count on a '-text' parameter being available in grass63.bat. We could have another .bat file which contains the call to gm.tcl and the exit clean up routines and call this .bat file with start /min from Init.bat. However, if you give it a .bat file, start will keep the cmd window open even after the script finishes. This means you have to then maximize the window and close it yourself... So, currently, the only satisfying options I see is to either teach people how to make a shortcut to their desktop (or wherever they want) and to configure this shortcut to minimize the cmd.exe window, or to create some sort of executable (in tcl, python or whatever) that calls grass63.bat. But maybe someone else has a better 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 True. > 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. Ok, won't for now, then. >> 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? Yes, definitely. Do I understand correctly that this would mean that instead of running $(BIN)/$(PGM).bat: $(MODULE_TOPDIR)/scripts/windows_launch.bat^M sed -e "s#SCRIPT_NAME#$(PGM)#" $(MODULE_TOPDIR)/scripts/windows_launch.bat > $@ on every script, we only run it for those scripts which do not have an equivalent .bat in the scripts directory ? Currently this would only concern gis.m, but if someone writes a cmd.exe replacement of another script, this would also be included. > but have a regular connection again so should hopefully be able to > contribute a bit more now. Great to have you back ! Moritz _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
