wingrass: background dosbox from regular wxgui startup

[hamish]

Hi,

after installing the latest 6.4.3svn nightly build on a Windows7 machine, and double clicking on the new desktop icon to launch the wxGUI, there's an empty dosbox just sitting there on the screen.

this is a regression from 6.4.2; ISTR that the place in the nsi installer where the icons are created is where you can tell it to auto-minimize the dosbox (you can also do it manually by right clicking on the "GRASS GIS $ver" icon Properties and selecting minimize from a drop-down menu). But really it should do like the tcl/tk GUI does from the Windows start menu and just flash one up and then have it go away (and even then, telling the one that flashes up to be minimized by default would be less disconcerting/more professional than seeing a black box blink by).

thanks, Hamish

[hamish]

this is unsightly, but not a really a blocker.

[neteler]

Tested on Windows8: the black dosbox also here and no command line (maybe not released but stuck? Or it should be minimized). When entering CTRL-C in this box, it ask if to interrupt a batch job. Confirming that, the GRASS session ends.

[hellik]

Replying to neteler:

Tested on Windows8: the black dosbox also here and no command line (maybe not released but stuck?

see ​http://trac.osgeo.org/grass/ticket/1103

[neteler]

Replying to neteler:

Tested on Windows8: the black dosbox also here and no command line

I seem to understand:

• sometimes messages are printed in this black dosbox, no other functionality (hence it should just be minimized perhaps)
• if you want command line, use the MSYS startup procedure

[hamish]

see also the SW_SHOWMINIMIZED vs. SW_SHOWNORMAL in the icon setup in mswindows/GRASS-Installer.nsi.tmpl.

(maybe you can right click properties or edit the .lnk shortcuts to try different values?)

I suspect if error messages do show up in there, the window will close before you could read them. ? I'm not sure, would have to try old copies of the installer, but I think this extra window is new behavior. ?

Hamish

[hellik]

Replying to neteler:

Replying to neteler:

Tested on Windows8: the black dosbox also here and no command line

see ​http://trac.osgeo.org/grass/ticket/1891?replyto=4#comment:3

any idea to get this running

I seem to understand:

• sometimes messages are printed in this black dosbox, no other functionality (hence it should just be minimized perhaps)
• if you want command line, use the MSYS startup procedure

IMHO we should get rid of the MSYS-commandline and only use the windows-CMD, it already works in winGRASS7 in this way.

[hamish]

Replying to hellik:

IMHO we should get rid of the MSYS-commandline and only use the windows-CMD, it already works in winGRASS7 in this way.

-1

thanks, Hamish

[glynn]

Replying to hellik:

IMHO we should get rid of the MSYS-commandline and only use the windows-CMD, it already works in winGRASS7 in this way.

As GRASS 6.x requires bash, the user should be given the option to launch a session using bash instead of cmd.exe. Either shell should be run using the Windows console; MSys' rxvt is quite buggy and isn't compatible with pdcurses.

[hellik]

Replying to glynn:

Replying to hellik:

IMHO we should get rid of the MSYS-commandline and only use the windows-CMD, it already works in winGRASS7 in this way.

As GRASS 6.x requires bash, the user should be given the option to launch a session using bash instead of cmd.exe. Either shell should be run using the Windows console; MSys' rxvt is quite buggy and isn't compatible with pdcurses.

thanks for clarification of my bad description, of course I've meant rxvt.

[hamish]

Hi,

see also #1103, this one is a semi-duplicate ticket.

after a little hunting, I notice the tooltip for the start wxGUI is "Launch GRASS ${VERSION_NUMBER} with wxGUI and CMD console", but since then the CMD console was switched off in favor of GUI-only mode, so the comment is a little out of date. maybe the empty window is more hangover effect?

You can right click on the grass65svn.bat shortcut and go to Properties -> Shortcut Tab -> Run: and change to "Minimized", but I wonder why SW_SHOWMINIMIZED from the CreateShortCut in GRASS-Installer.nsi.tmpl is not always respected? Maybe if you click on the taskbar button for it it remembers the last-used state instead of the installer's original state?

... is there a way in windows to run a .bat file without opening a dos box?

Hamish

[glynn]

Replying to hamish:

... is there a way in windows to run a .bat file without opening a dos box?

AFAICT, if you execute a console program (such as cmd.exe) via Explorer, the console is shown automatically (although you can configure it to minimise the console).

You can execute a .bat file from another program without the console being shown. E.g. if the Python script:

import subprocess
subprocess.call('test.bat', shell=True)

is given a .pyw extension, running the .pyw file via Explorer will execute the .bat file without a console being shown.

[hamish]

Replying to hamish:

... is there a way in windows to run a .bat file without opening a dos box?

Replying to glynn:

AFAICT, if you execute a console program (such as cmd.exe) via Explorer, the console is shown automatically (although you can configure it to minimise the console).

which is what we've done, but if you unminimize it it seems to remember that state for next time(?). at least with Windows7 the taskbar buttons gets grouped so it's less obvious there.

You can execute a .bat file from another program without the console being shown. E.g. if the Python script:

import subprocess
subprocess.call('test.bat', shell=True)

is given a .pyw extension, running the .pyw file via Explorer will execute the .bat file without a console being shown.

(ok; & so run by pythonw.exe not python.exe)

This is for the main grass64svn.bat Init script, which also needs to do -text and -tcltk without a working python, so I suspect it's more trouble that it's worth. Another alternative to get rid of it might be a tiny C program to launch the .bat file..

here's a similar solution using a .vbs wrapper:

​http://www.tomshardware.com/forum/245566-45-batch-file-window-poping

Perhaps in grass7 where the startup script is a .py it's simpler to do the .pyw wrapper?

Hamish

[hamish]

hopefully with r55886 the dos box is now minimized when grass is launched from the desktop icon (devbr6).

[hellik]

Replying to hamish:

hopefully with r55886 the dos box is now minimized when grass is launched from the desktop icon (devbr6).

r55888 - grass/trunk/mswindows cmd terminal was removed so remove it from the tooltip; minimize the dos box (merge from devbr6)

why in wingrass7? CMD terminal is usable there...

[hellik]

Replying to hellik:

why in wingrass7? CMD terminal is usable there...

as example see here: ​http://grasswiki.osgeo.org/wiki/R_statistics#GRASS_7_Usage

[hamish]

Replying to hellik:

why in wingrass7? CMD terminal is usable there...

ok, I didn't know that, happy to switch it back for g7.

I thought whoever switched off the CMD window in 6.x wingrass did it because the command line was considered "scary" to Windows users, not to hide something that wasn't usable. (I don't really have a strong opinion either way on what should be the default, power users can always copy their favorite grass-startup-mode icon to the desktop, just that it would be nice if the help page examples were easy to cut and paste somewhere, and "just work")

?, Hamish

[hamish]

It's beginning to dawn on me that the subject of this bug report may be due to a bug, there's a GRASS> prompt in that batch file trying to get out; and not the result of an intentional change... in which case my last commit minimizing the dos box was wrong.

[hamish]

and by "subject of this bug report" I mean the subject of #1103 WinGrass64 - windows-commandline not released ...

ok, that's me signing off for the night :)

[hellik]

Replying to hamish:

Replying to hellik:

why in wingrass7? CMD terminal is usable there...

ok, I didn't know that, happy to switch it back for g7.

yes please, thanks.

I thought whoever switched off the CMD window in 6.x wingrass did it because the command line was considered "scary" to Windows users, not to hide something that wasn't usable.

the latter

(I don't really have a strong opinion either way on what should be the default, power users can always copy their favorite grass-startup-mode icon to the desktop, just that it would be nice if the help page examples were easy to cut and paste somewhere, and "just work")

help page examples can be copied/pasted in the windows CMD, I vote for "with CMD" as default

[hellik]

Replying to hamish:

It's beginning to dawn on me that the subject of this bug report may be due to a bug, there's a GRASS> prompt in that batch file trying to get out;

maybe yes

and not the result of an intentional change... in which case my last commit >minimizing the dos box was wrong.

yes, if #1103 could be fixed

Helmut

[mlennert]

Replying to hellik:

Replying to hamish:

I thought whoever switched off the CMD window in 6.x wingrass did it because the command line was considered "scary" to Windows users, not to hide something that wasn't usable.

the latter

(I don't really have a strong opinion either way on what should be the default, power users can always copy their favorite grass-startup-mode icon to the desktop, just that it would be nice if the help page examples were easy to cut and paste somewhere, and "just work")

help page examples can be copied/pasted in the windows CMD, I vote for "with CMD" as default

+1

Moritz

[hamish]

Replying to hellik:

Replying to hamish:

Replying to hellik:

why in wingrass7? CMD terminal is usable there...

ok, I didn't know that, happy to switch it back for g7.

yes please, thanks.

done

[hamish]

in light of this r55908 and r55889 should be reverted.

[hamish]

any more votes/comments/objections before spending time on getting the grass terminal working again? so far we have two +1s and my +0.

should we keep it running DOS, or try for bash-in-a-dos-box before release?

Hamish

[hellik]

Replying to hamish:

any more votes/comments/objections before spending time on getting the grass terminal working again? so far we have two +1s and my +0.

should we keep it running DOS, or try for bash-in-a-dos-box before release?

see

#1891#comment:8

[hamish]

I don't think we should consider getting rid the rxvt + msys command line until the cmd.exe + bash actually works. We can revisit the issue once it does.

Fixing a couple of things in init.bat yesterday it was apparent that the :wxpython gui goto target in init.bat is currently written to launch the wxGUI without a real command window, so an intentional change. I don't say that is right or wrong, just fyi the way it currently is written.

Hamish

ps- I suggest we create a new sub-menu in the Start->Program Files->GRASS menu, to contain the lesser used startup methods (command line only, tcl/tk gui, ...), as it's a bit cluttered right now. I'm not sure where the MSYS UNIX-only one should go, maybe into another Utilities menu?

[glynn]

Replying to hamish:

should we keep it running DOS, or try for bash-in-a-dos-box before release?

The last version of Windows to include a version of DOS was Windows ME. cmd.exe is not DOS, and the command-line utilities are not DOS programs, even if they are largely compatible with the original DOS programs with the same names.

Ideally, GRASS 6.x should include options to start a GRASS session: a) using cmd.exe in a console window, and b) using bash in a console window. It shouldn't include any options which involve MSys' rxvt, as it's just too buggy (and won't work with any curses-based programs, which require a normal console window).

Windows users shouldn't be expected to be familiar with bash.

[mmetz]

Replying to glynn:

Replying to hamish:

should we keep it running DOS, or try for bash-in-a-dos-box before release?

Ideally, GRASS 6.x should include options to start a GRASS session: a) using cmd.exe in a console window, and b) using bash in a console window.

+1

It shouldn't include any options which involve MSys' rxvt, as it's just too buggy (and won't work with any curses-based programs, which require a normal console window).

FWIW, MSYS uses (since 2009.03.17) by default sh, not rxvt. Only the ancient msys.bat in GRASS 6 uses rxvt by default. The MSYS console in GRASS 7 uses sh.

[hamish]

Replying to mmetz:

FWIW, MSYS uses (since 2009.03.17) by default sh, not rxvt. Only the ancient msys.bat in GRASS 6 uses rxvt by default. The MSYS console in GRASS 7 uses sh.

... rxvt is the xterm-alike window-frame, sh is the Bourne shell (#!/bin/sh, in the case of MSys "symlinked" to bash.exe), right? are we comparing apples and oranges? or is there another sh.exe from Microsoft or MSys acting as a graphical xterm-alike window and not a Bourne shell interpreter?

either way, let's not start anything new and delay 6.4.3 for a transition/debugging, it can go in for the next one. Besides the known pdcurses issue (I've used the msys+rxvt a bunch and it's hasn't bothered me) the rxvt-MSys on 6.4.3svn is the least problematic of the startup methods on wingrass right now. It ain't (very) broke, let's not fix it while cmd.exe and friends are actively being transitioned from mostly-broken to hopefully-working.

for the 6.4.3 release right now we offer these options:

• Command Line (grass in C:\>, just fixed in devbr6; will backport v.soon)
• GUI (wxGUI without a separate command window; sibling to the desktop icon)
• GUI with MSYS (wxGUI with bash running in a rxvt window)
• Old TclTk GUI (no rxvt window, just the GUI windows(?))
• MSYS UNIX Console (bash in rxvt, not in a GRASS environment)

the desktop icon is not exactly the same as the "GUI" from the menu, but AFAIK the only difference is the minimizing of the empty dosbox window. Whatever the desktop icon is effectively defines the "default" presentation.

grass643.bat in the 'C:\Program Files\GRASS GIS' dir calls etc/env.bat then etc/Init.bat for the startup, with the exception of "GUI+MSys" which calls "./msys/msys.exe grass643.sh -wx".

I'm sort of confused as to the goal we are working towards-

• which of the options do we want the "default" presentation to be?
• otherwise are we happy with: cmd.exe only, GUI only, and GUI+bash?
• if the answer to the first question is GUI+bash, will bash be in rxvt for 6.4.3 and a dosbox for 6.4.4? or some other plan?
• if for 6.4.3 the "default" desktop icon target is GUI-only, do we write a simple .pyw wrapper to call 'grass643svn.bat -wxpython' launcher to avoid the empty dosbox? (the subject of this ticket)
• do we ease the non-default startup options into a sub-menu to reduce the clutter? or just let the user adjust the desktop icon to whichever version they like?

thanks, Hamish

ps- is the occasional unwanted "C:" -> "/c/" conversions in random strings by msys still a problem in trunk?

[mmetz]

Replying to hamish:

Replying to mmetz:

FWIW, MSYS uses (since 2009.03.17) by default sh, not rxvt. Only the ancient msys.bat in GRASS 6 uses rxvt by default. The MSYS console in GRASS 7 uses sh.

... rxvt is the xterm-alike window-frame, sh is the Bourne shell (#!/bin/sh, in the case of MSys "symlinked" to bash.exe), right? are we comparing apples and oranges? or is there another sh.exe from Microsoft or MSys acting as a graphical xterm-alike window and not a Bourne shell interpreter?

You do not need rxvt to offer bash in a console window. The MSYS console window does not use rxvt by default as of 2009.03.17.

either way, let's not start anything new

Having been the default for 4 years means "new"? Because of the problems with rxvt, I have been using the official MSYS default (cmd.exe + sh.exe) for the last few years in my on wingrass versions as of 6.4.1.

Markus M

[glynn]

Replying to hamish:

FWIW, MSYS uses (since 2009.03.17) by default sh, not rxvt. Only the ancient msys.bat in GRASS 6 uses rxvt by default. The MSYS console in GRASS 7 uses sh.

... rxvt is the xterm-alike window-frame, sh is the Bourne shell (#!/bin/sh, in the case of MSys "symlinked" to bash.exe), right?

Right. bash.exe (aka sh.exe aka /bin/sh) and cmd.exe are shells: programs which read commands from stdin and execute them. rxvt and "the console window" (conhost.exe) are terminal emulators.

The two are orthogonal: you can run either shell in either terminal emulator.

We should offer a choice of shell: bash is more functional, but there's no reason to expect Windows users to be familiar with it. There's no reason to offer a choice of terminal emulator; the one which is built into Windows is more robust and more functional (apart from anything else, programs will actually recognise it as a terminal; the isatty() function returns true for the built-in console window and false for anything else, including rxvt).

[hamish]

Hi,

rxvt is nothing to do with this bug beyond that's the only 6.x shell which is currently working (mostly) problem free. I've opened #1950 for further discussion on replacing it.

--- the task in this ticket is to decide if the GUI without a real terminal window is what we want as the default, or not, and if so consider to replace the grass643.bat file created by the NSIS installer with a new grass643.pyw. (the .bat is just a 4 liner which sources env.bat (itself just 13 setenv()s) and launches Init.bat, should be easy)

... or if we just continue to live with the minimized empty dosbox in the taskbar.

thanks, Hamish

[glynn]

Replying to hamish:

rxvt is nothing to do with this bug beyond that's the only 6.x shell

rxvt isn't any kind of shell.

[hamish]

outstanding issues:

• to write a .pyw wrapper for wingrass startup?
• which is the desired default startup method? the discussion in this ticket is in conflict with the current implementation.

[neteler]

The current nightly winGRASS 6.4.3svn no longer starts:

• wx GUI start broken- flash of dosbox only
• old tcltk start broken - nothing happens
• cmd mode start broken - nothing happens

Only the MSYS start is functional. I don't know if this is the right ticket but it is BAD to break everything in after RC3.

[hellik]

Replying to neteler:

The current nightly winGRASS 6.4.3svn no longer starts:

• wx GUI start broken- flash of dosbox only
• old tcltk start broken - nothing happens
• cmd mode start broken - nothing happens

Only the MSYS start is functional. I don't know if this is the right ticket but it is BAD to break everything in after RC3.

wingrass standalone or osgeo4w-wingrass?

tested here with

GRASS version: 6.4.3svn                                                         
GRASS SVN Revision: 56101                                                       
GIS Library Revision: 50937 (2012-02-25)                                        
GDAL/OGR: 1.9.2                                                                 
PROJ4: Rel. 4.8.0, 6 March 2012                                                 
Python: 2.7.4                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)   

[can't test standalone cause of a nasty dll hell - aka interfering installed python vs. bundled python]

Helmut

[hamish]

Replying to neteler:

The current nightly winGRASS 6.4.3svn no longer starts:

• wx GUI start broken- flash of dosbox only
• old tcltk start broken - nothing happens
• cmd mode start broken - nothing happens

Only the MSYS start is functional. I don't know if this is the right ticket but it is BAD to break everything in after RC3.

the three you see not working start with init.bat; the msys startup is different, it uses like 'msys.bat -c init.sh' (not exactly that, but in effect).

I've just tried again on XP with the r56101 nightly pkg build of 6.4.3svn, everything works fine for me.

• did you select the box for installing "Important Microsoft runtime dll's"? (again, if not selected I suspect we need an extra warning installer page with [<Back<] [>Forward>] buttons to give the user a second opportunity to select it)

• can you recreate from the command line to see the error message? right-click on the menu item, look at the properties to get startup dir and command name, open a dosbox, cd into the startup dir and paste in the startup command.

• the only recent change to relbr64's init.bat is r56104. (which works fine for me, and should not affect the wxGUI startup at all, so I'm doubtful it's the cause)

or maybe there is some other dll missing. You're not using some exotic C:\Program Files\ or Docs & Settings install location?

Helmut wrote:

[can't test standalone cause of a nasty dll hell - aka interfering installed python vs. bundled python]

at install time or run time? You should be able to change GRASS_PYTHON to the exact c:\path\python.exe you want to use in %GISBASE%/etc/env.bat.

Hamish

[hamish]

Replying to hamish:

I've just tried again on XP with the r56101 nightly pkg build of 6.4.3svn, everything works fine for me.

...

• the only recent change to relbr64's init.bat is r56104.

(which of course is newer than the installer, so not responsible. The prior change to that was r55971, 11 days ago, which is an important fix)

Hamish

[hamish]

Replying to hamish:

Helmut wrote:

[can't test standalone cause of a nasty dll hell - aka interfering installed python vs. bundled python]

at install time or run time? You should be able to change GRASS_PYTHON to the exact c:\path\python.exe you want to use in %GISBASE%/etc/env.bat.

... and since %GISBASE%/etc/env.bat gets replaced at reinstall, you can also create a personal env.bat in your %APPDATA%/GRASS6/ dir, which is called after the system version, that way your local environment changes survive reinstall.

Hamish

[neteler]

Replying to hamish:

Replying to neteler:

The current nightly winGRASS 6.4.3svn no longer starts:

I am using wingrass standalone on Windows8 (as before).

• did you select the box for installing "Important Microsoft runtime dll's"?

No since I had done this already the last time.

(again, if not selected I suspect we need an extra warning installer page with [<Back<] [>Forward>] buttons to give the user a second opportunity to select it)

I don't think so: I guess I should select it only once (here, done 2 weeks ago, see ticket), then the machine should be ok? Otherwise we should always force to install it if *this* is the problem (cannot test right now).

• can you recreate from the command line to see the error message? right-click on the menu item, look at the properties to get startup dir and command name, open a dosbox, cd into the startup dir and paste in the startup command.

Will do later on.

• the only recent change to relbr64's init.bat is r56104. (which works fine for me, and should not affect the wxGUI startup at all, so I'm doubtful it's the cause)

or maybe there is some other dll missing. You're not using some exotic C:\Program Files\ or Docs & Settings install location?

The entire purpose of my Windows8 installation which came with my new laptop is to test GRASS GIS. I simply download the standalone installer and run it. No other tricks done. Since the older installers worked while now broken for me I suspect some recent change.

Helmut wrote:

[can't test standalone cause of a nasty dll hell - aka interfering installed python vs. bundled python]

at install time or run time? You should be able to change GRASS_PYTHON to the exact c:\path\python.exe you want to use in %GISBASE%/etc/env.bat.

As written, also the Tcl-Tk startup is broken for me at time.

I also deinstalled/reinstalled, no way.

[hamish]

Replying to neteler:

Replying to hamish:

• did you select the box for installing "Important Microsoft

runtime dll's"?

No since I had done this already the last time.

you've got to do it every time. the needed msvcr70.dll & similar are al a carte in the downloaded tarball, and get installed to C:\Program Files\GRASS...\extralib, so are install specific, & need to be done for each time, for each version. AFAIK only the 2010.exe installer puts the msvcr100.dlls in C:\windows\system32 and so survives. I don't know what the 2005.exe and 2008.exe installers actually install (but I'd like to).

So the three ms-$year.exe installers run, but also a number of dlls are in the tarball and copied separately. The three ms-$year installers should survive reinstall, but don't provide all the Microsoft-provided libraries we need.

probably(?) there is some other ms redistributable installer which installs the ones we need system wide, I don't know. note the 80 and 90 msvcr dlls are still missing (see #1428), probably causing breakage once the fns that need them get called.

I don't like us installing to c:\windows\system32, I'd rather have ms's installers do that with their full checks, registry registration, and inside knowledge.

(again, if not selected I suspect we need an extra warning installer page with [<Back<] [>Forward>] buttons to give the user a second opportunity to select it)

I don't think so: I guess I should select it only once (here, done 2 weeks ago, see ticket),

(nope, every time)

then the machine should be ok? Otherwise we should always force to install it

mmph. I don't think we can or should make it mandatory, but we might be able to change the default on the download page to ticked instead of unticked.

if *this* is the problem (cannot test right now).

I'm pretty sure it will be #1428.

another idea is to have a tiny sacrificial osgeo4w program that runs with a dependency on all dlls used by the core osgeo4w toolchain, and catch the result so at least there is a nice error message telling you what to do instead of the not very helpful vanishing box. Who c/would write it? no idea.

Hamish

[hamish]

Replying to hamish:

I don't think we can or should make it mandatory,

as per ​http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

Hamish

[neteler]

Replying to hamish:

Replying to neteler:

Replying to hamish:

• did you select the box for installing "Important Microsoft

runtime dll's"?

No since I had done this already the last time.

you've got to do it every time.

... I omitted to say that I have done this only during the last but one personal test round. Originally there was no need to install these DLLs at all on my Win8 box. Hence uninstallation of GRASS should not have changed that situation.

/me confused

[hamish]

Replying to neteler:

... I omitted to say that I have done this only during the last but one personal test round. Originally there was no need to install these DLLs at all on my Win8 box. Hence uninstallation of GRASS should not have changed that situation.

/me confused

older development versions of the installer were quietly shipping the MS visual runtime dlls, and copying them to $GISBASE/extralib/ every time. that is not allowed by the license, so a couple of weeks ago it was changed to download them instead, at the user's request. so it depends if your last install was older than a couple of weeks ago or not.

they were probably never installed system-wide on your computer, and disappeared and reappeared within the current $GISBASE with every uninstall and reinstall.

it also seems that in the last month or two there was another change in the situation when whoever builds either python.exe &/or the osgeo4w stack switched to a newer development environment which wanted the new msvcr100 dlls, while older programs shipping with those tools still want the older versions of the runtime dlls.

the root of all this fun of course is that Microsoft makes them a standard part of their compiler builds, but doesn't ship them as standard OS libraries, and then makes installing them later by the end-user a total pain in the neck. but there's not much we can do about that.

Hamish

[neteler]

Replying to hamish:

Replying to neteler:

... I omitted to say that I have done this only during the last but one personal test round. Originally there was no need to install these DLLs at all on my Win8 box. Hence uninstallation of GRASS should not have changed that situation.

/me confused

older development versions of the installer were quietly shipping the MS visual runtime dlls, and copying them to $GISBASE/extralib/ every time. that is not allowed by the license, so a couple of weeks ago it was changed to download them instead, at the user's request. so it depends if your last install was older than a couple of weeks ago or not.

No, not the case.

I tested it by manually trying to start GRASS in cmd.exe. The error is not the DLL hell but that the path is not found, something like

"\GRASS not found bla bla"

(German language, I tried to capture the screenshot but the file disappeared while transiting back to Linux). In essence, the grass64svn.bat looks like this:

Program Files (x86)\GRASS GIS 6.4.3svn\grass64svn.bat 
@echo off
rem #########################################################################
rem #
rem # File dynamically created by NSIS installer script;
rem #
rem #########################################################################
rem #
rem # GRASS Initialization
rem #
rem #########################################################################

set GISBASE=C:\Program Files (x86)\GRASS GIS 6.4.3svn

call "%GISBASE%\etc\env.bat"

cd "%USERPROFILE%"
"%GISBASE%\etc\Init.bat" %*

To me it looks like a problem of the unquoted GISBASE.

If anyone has winGRASS 6.4.3RC3 standalone installed, please compare if this bat file also contains an unquoted GISBASE path setting with white space.

[hamish]

Replying to neteler:

Replying to hamish:

[...] shipping the MS visual runtime dlls,

No, not the case.

ok,

I tested it by manually trying to start GRASS in cmd.exe. The error is not the DLL hell but that the path is not found, something like

"\GRASS not found bla bla"

(German language, I tried to capture the screenshot but the file disappeared while transiting back to Linux).

alright. the exact message might be useful, next time you're there could you try again to get the screenshot?

In essence, the grass64svn.bat looks like this:

 Program Files (x86)\GRASS GIS 6.4.3svn\grass64svn.bat 
 @echo off
 rem #########################################################################
 rem #
 rem # File dynamically created by NSIS installer script;
...
 set GISBASE=C:\Program Files (x86)\GRASS GIS 6.4.3svn
 call "%GISBASE%\etc\env.bat"
 cd "%USERPROFILE%"
 "%GISBASE%\etc\Init.bat" %*

To me it looks like a problem of the unquoted GISBASE.

If you are thinking of the "set GISBASE=" line, AFAIK in batch files anything to the right of the "=" becomes part of the string, so no need to quote those. And if you do quote, they become a literal part of the string as it doesn't parse them away.

If anyone has winGRASS 6.4.3RC3 standalone installed, please compare if this bat file also contains an unquoted GISBASE path setting with white space.

(all works for me on 32bit XP, with no (x86) in the Program Files)

could you try adding some echo statements to $GISBASE/etc/env.bat and $GISBASE/etc/Init.bat to see how far it gets?

thanks, Hamish

[neteler]

grass643svn.bat startup, yet ok

[neteler]

GRASS 6.4.3svn Init.bat problem

[neteler]

GRASS 6.4.3svn Init.bat problem: failure

[neteler]

I have attached screenshots. The problem is in Init.bat

if "%PYTHONPATH%" == "" (
	set PYTHONPATH=%GISBASE%\etc\python
) else (
	set PYTHONPATH=%PYTHONPATH%;%GISBASE%\etc\python
)

[hamish]

Replying to neteler:

I have attached screenshots. The problem is in Init.bat

if "%PYTHONPATH%" == "" (
	set PYTHONPATH=%GISBASE%\etc\python
) else (
	set PYTHONPATH=%PYTHONPATH%;%GISBASE%\etc\python
)

Hi,

I tried on Windows7 (instead of XP as earlier) and I could reproduce the same error there. The English version of the error message is "/GRASS was unexpected at this time."

the method seems pretty much the same as the GRASS_WISH and GRASS_GUI ones nearby, so I'm not sure what would be wrong with it, or why it matters in 7,8 but not XP, but it seems to be treating the forward-slash dirseps in GISBASE as a switch(?).

try r56137,8.

an alternative solution might be to try to pass the 8.3 shortname version of %GISBASE%. (echo %~sI)

Hamish

[neteler]

I tried with toda's binary snapshot: r56138 solved it for 6.4.3svn and brought the startup back. The dosbox is minimized as desired.

Minor (new?) issue: The wxGUI start window should come to top, but it hides behind this trac browser windows when starting.

[hamish]

Replying to neteler:

The dosbox is minimized as desired.

which is nice for the current condition of having an empty dosbox, but just to restate the ideal goal: either present the GRASS> prompt in the dosbox terminal(1), or don't present a terminal window at all(2) and use a wrapper like .pyw to avoid the superfluous empty dosbox.

(1)current way in G7, some votes to do that in G6

(2)current way in G6, no votes so far to keep it

--but not touching it without more feedback.

Hamish

[marisn]

Replying to hamish:

Replying to neteler:

The dosbox is minimized as desired.

(1)current way in G7, some votes to do that in G6

Current approach in G7 is broken by design.

When the user starts GRASS for the first time, grass70.py is printing in the CMD window "Welcome to blahblah press RETURN to continue". As of current nightly, CMD window is minimised thus user doesn't see that message. From ~20 persons only one guessed correctly - hey, there could be something important in that minimized window!

Potential solutions:

• do not print a welcome message in CMD. Why it could not be a pop-up in WXGUI?
• do not minimize CMD window by default.

The GRASS configuration information is stored ONLY when user types into CMD "exit" to close the minimized window. Out of ~20 users NONE knew the necessity to maximize the CMD window and type in "exit" instead of just closing the CMD window.

Potential solutions:

• do not release CMD when starting gui. Thus on GUI exit it would be possible to close CMD too and write out configuration data, clean up TMP files etc. CMD could be provided by a separate icon - "GRASS GUI with CMD".
• do not minimize CMD window if one expects to type "exit" to close it.
• or better - trap window close event and run "exit" part of code to clean up on such event.

Adding to this ticket, as decision making process has been made here.

[glynn]

Replying to marisn:

• do not print a welcome message in CMD. Why it could not be a pop-up in WXGUI?

GUI? What GUI? ;)

We should consider re-factoring the start-up script into separate scripts for the GUI and command line.

If the script is run with pythonw.exe (rather than python.exe), the user need never see a console window. However, this does require that the GUI never writes to stdout/stderr, and that it ensures that those streams are redirected for any child processes which might do so.