wingrass: replace rxvt with conhost.exe

[hamish]

Making a new ticket for this as it has little to do with #1891.

the task: replace msys's rxvt.exe with Microsoft's built in conhost.exe terminal emulator.

IIUC, conhost.exe is new for Windows7, Windows XP doesn't have it. At least mine doesn't in C:\windows\system32. If so that's a problem, half of the world's installed Windows systems are still running XP.

know problems with MSys's rxvt:

• not compatible with pdcurses (e.g. r.support run from the command line, edit categories will fail)
• isatty() function returns false
• ?

(I've used it a bunch and not run into any problems, so beyond the above I'm not really seeing what all the fuss is about. what exactly about it is buggy?)

the bug where msys converts and C: to /c/ in strings when you don't want it to -- is that msys's rxvt or something else in their bash.exe?

since msys+rxvt is the most stable of the grass Command Line menu items right now, I'd strongly suggest to delay replacement of it until 6.4.3 is out the door.

thanks, Hamish

[hamish]

Replying to hamish:

IIUC, conhost.exe is new for Windows7, Windows XP doesn't have it. At least mine doesn't in C:\windows\system32.

maybe it is csrss.exe there?

[mmetz]

Replying to hamish:

Replying to hamish:

IIUC, conhost.exe is new for Windows7, Windows XP doesn't have it. At least mine doesn't in C:\windows\system32.

maybe it is csrss.exe there?

Can you test if GRASS 7 with MSYS console works for you? Because there the MSYS console does not use rxvt and does not care about csrss.exe or conhost.exe, it simply starts sh as a shell in msys.bat.

Markus M

[hamish]

Replying to mmetz:

Can you test if GRASS 7 with MSYS console works for you?

I haven't tested it extensively, but yes, the msys bash command prompt for grass7 wingrass works on XP.

Because there the MSYS console does not use rxvt and does not care about csrss.exe or conhost.exe, it simply starts sh as a shell in msys.bat.

fwiw, looking in the taskman, sh.exe seems to be running in csrss.exe there.

the existing trouble with grass6 cmd.exe Command Line mode is that shell scripts run within shell scripts can't find them. (e.g. v.in.lines(.sh) calling v.in.mapgen(.sh) seen in another bug report) It's not something which is done in trunk so untested with shell scripts. This is the class of new subtle bug I'm worried about introducing into 6.x if we make a last minute change away from rxvt for 6.4.3 since there's little time for testing. In the days before release, tested>>theoretically better.

thanks, Hamish

[glynn]

Replying to hamish:

the task: replace msys's rxvt.exe with Microsoft's built in conhost.exe terminal emulator.

IIUC, conhost.exe is new for Windows7, Windows XP doesn't have it. At least mine doesn't in C:\windows\system32. If so that's a problem, half of the world's installed Windows systems are still running XP.

The console window was part of the csrss.exe (Client-Server Runtime Sub-System) service prior to Windows 7.

The exact details aren't important; all versions of Windows automatically create a console window if a "console mode" program is run without an existing console (e.g. from a desktop icon or start menu entry).

(I've used it a bunch and not run into any problems, so beyond the above I'm not really seeing what all the fuss is about. what exactly about it is buggy?)

I've found that copy+paste often caused rxvt to crash. But given that a number of 6.x modules either use curses or modify their behaviour depending upon whether isatty() returns true for stdin/stdout, the fact that rxvt won't work correctly with those modules can also be considered a bug.

the bug where msys converts and C: to /c/ in strings when you don't want it to -- is that msys's rxvt or something else in their bash.exe?

That's bash. And it's largely unavoidable if it's to be compatible with scripts written for Unix.

[glynn]

Replying to hamish:

the existing trouble with grass6 cmd.exe Command Line mode is that shell scripts run within shell scripts can't find them. (e.g. v.in.lines(.sh) calling v.in.mapgen(.sh) seen in another bug report)

That's because $GISBASE/scripts isn't added to PATH on Windows.

bash has its own execution mechanism; in particular, it doesn't use PATHEXT, so you can't run a batch file without specifying the .bat or .cmd extension. But because shell scripts don't have a .sh extension (and the .sh extension probably isn't associated with bash anyhow), they can't just be "executed" normally. So GRASS 6.x creates a .bat file in $GISBASE/bin for each shell script.

This works when executing scripts via cmd.exe, system(), subprocess.Popen(), etc, as those all use PATHEXT. But bash doesn't use PATHEXT, so it doesn't find the .bat files, and it doesn't find the scripts themselves because $GISBASE/scripts isn't in $PATH.

Maybe adding $GISBASE/scripts to PATH in scripts/windows_launch.bat would work? Or it might not, as the updated PATH would be inherited by anything run from the script; presumably there's a reason for $GISBASE/scripts being excluded from PATH, rather than just being after $GISBASE/bin.

[mmetz]

Replying to glynn:

Replying to hamish:

(I've used it a bunch and not run into any problems, so beyond the above I'm not really seeing what all the fuss is about. what exactly about it is buggy?)

The only fuss I see is about keeping rxvt. I don't see what all the fuss is about. It has been settled for MSYS four years ago.

I've found that copy+paste often caused rxvt to crash. But given that a number of 6.x modules either use curses or modify their behaviour depending upon whether isatty() returns true for stdin/stdout, the fact that rxvt won't work correctly with those modules can also be considered a bug.

In rxvt, copy+paste never worked for me, but since I am sometimes trying to fix bugs for wingrass, I changed years ago to system console + sh in my local wingrass versions.

It seems that using rxvt can be regarded as a bug. I updated msys.bat to the official stable version (MSYS 2009) in r55996,7 for rebr64, devbr6, respectively.

About changes and testing: this change is not in a release candidate and far from being in an official release. A pity.

[hamish]

Replying to mmetz:

The only fuss I see is about keeping rxvt.

I don't care about keeping rxvt. I have no problem with replacing it if it's for the best. What I care about is last minute untested [in 6.x] changes in the release branch, and keeping the development team a nice community to participate in.

In rxvt, copy+paste never worked for me,

I've used it a lot and never had a problem with that, shrug. Just re-tested: in rxvt highlight + middle click + external ^{V in textpad works perfectly for me (both directions), and a /lot/ less annoying than menu, mark, menu, cut, then menu, paste in a dosbox. fwiw rxvt font size options are nicer too.. ;-)}

but since I am sometimes trying to fix bugs for wingrass, I changed years ago to system console + sh in my local wingrass versions.

so you've no experience with the current version and are basing your impression on some years old thing?

It seems that using rxvt can be regarded as a bug.

the question is if it is a serious enough problem to risk destabilizing the one wingrass command line option in 6.x which is 99% working properly, shortly before a public release. !@$!#@$

I updated msys.bat to the official stable version (MSYS 2009) in r55996,7 for rebr64, devbr6, respectively.

thanks for respecting the "just wait a bit" requests of others... great collaborative working environment based on mutual respect we have here.

by the way, you overwrote some local changes to the msys.bat script in your commits. (i.e. our "%PART1%" test to see that paths with spaces were correctly quoted, see original commit to svn + #905, #629)

About changes and testing: this change is not in a release candidate and far from being in an official release. A pity.

Perhaps, but 6.4.4 doesn't have to be that far away. Shoving core stuff in at the last minute is bad bad bad bad, no matter how innocent looking it seems. Now we have something else to spend many hours testing, which is annoying. --have you started that? was your local replacement+testing done for 6.x or trunk?

I'm partly annoyed as we have a number of other major wingrass bugs to fix before release, it's hard to get anyone to work on them, and instead we seem to be wasting time and energy here discussing the bike shed.

thanks, Hamish

[mmetz]

Replying to hamish:

Replying to mmetz:

The only fuss I see is about keeping rxvt.

I don't care about keeping rxvt. I have no problem with replacing it if it's for the best. What I care about is last minute untested [in 6.x] changes in the release branch,

It was you how broke translation for 16 languages in the last minute. I do not expect to be GRASS 6.4.3rc4 to be released in the next minute.

and keeping the development team a nice community to participate in.

?

IMHO, what counts is releasing a stable version. Soon. You prevent this. This is, i.e you are, not nice.

In rxvt, copy+paste never worked for me,

I've used it a lot and never had a problem with that, shrug.

It is safer to use the system's console window.

but since I am sometimes trying to fix bugs for wingrass, I changed years ago to system console + sh in my local wingrass versions.

so you've no experience with the current version and are basing your impression on some years old thing?

Your thing is even older. Please keep the development team a nice community and do not post provoking posts.

I understand, I will immediately update mswindows/osgeo4w/msys.bat to the current stable version of msys. Oops, noting to update, stable since 2009.

It seems that using rxvt can be regarded as a bug.

the question is if it is a serious enough problem to risk destabilizing the one wingrass command line option in 6.x which is 99% working properly, shortly before a public release. !@$!#@$

Stabilizing, not destabilizing.

I updated msys.bat to the official stable version (MSYS 2009) in r55996,7 for rebr64, devbr6, respectively.

thanks for respecting the "just wait a bit" requests of others... great collaborative working environment based on mutual respect we have here.

The request to not use rxvt is rather old.

Why did you not "just wait a bit" before breaking translations?

by the way, you overwrote some local changes to the msys.bat script in your commits. (i.e. our "%PART1%" test to see that paths with spaces were correctly quoted, see original commit to svn + #905, #629)

These are not local changes. The part you refer to is not even in msys-1.0.11. Can you please provide an example where this test is needed?

About changes and testing: this change is not in a release candidate and far from being in an official release. A pity.

Perhaps, but 6.4.4 doesn't have to be that far away. Shoving core stuff in at the last minute is bad bad bad bad, no matter how innocent looking it seems. Now we have something else to spend many hours testing, which is annoying.

have you started that? was your local replacement+testing done for 6.x or trunk?

I spent years testing. In trunk and relbr64. Not in debr6, because there is no reason for the existence of devbr6. Please respond in the appropriate thread.

I'm partly annoyed as we have a number of other major wingrass bugs to fix before release, it's hard to get anyone to work on them, and instead we seem to be wasting time and energy here discussing the bike shed.

My .2c:

downgrade the osgeo4w python and wxpython versions upgrade msys and mingw fix grass-addons

thanks, Hamish

welcome,

Markus

[hamish]

Replying to hamish:

I don't care about keeping rxvt. I have no problem with replacing it if it's for the best. What I care about is last minute untested [in 6.x] changes in the release branch,

Replying to mmetz:

It was you how broke translation for 16 languages in the last minute.

consider 2/400 modules with possibly untranslated descriptions. consider also one of the main startup methods of grass about to be released with next to zero field testing. Which one is worth losing more sleep over?

(and again, I mean byte-for-byte in-place implementation in grass on a widespread section of end-user systems; time is the only tool we have against the subtle unforeseen bugs, it is unhumble of us to assume that we can know those).

I do not expect to be GRASS 6.4.3rc4 to be released in the next minute.

maybe not ever. straight to -final! :)

and keeping the development team a nice community to participate in.

?

IMHO, what counts is releasing a stable version.

We all agree on that. The best one we can. I'm trying to throw emphasis on the word "stable", by which I mean well tested and problems known + understood.

Soon. You prevent this. This is, i.e you are, not nice.

I do not apologize for filing blocker bugs for license violations or things like cmd.exe totally and completely failing to launch. We could not launch like that, but they are nearly fixed now so let's keep moving forward.

If I apologize for anything it's to Martin for sending an email the other day about using EPSG codes, which came out harsher than I meant it to for something still in early development.

But for reporting new bugs? No way.

Please keep the development team a nice community and do not post provoking posts.

What pissed me off is this: I asked to please wait for a bit before committing. You ignored and committed immediately anyway. So yeah, "thanks". That is no way for us to do business.

Why did you not "just wait a bit" before breaking translations?

no one asked for a strings-freeze AFAIK, if there was I missed it.

by the way, you overwrote some local changes to the msys.bat script in your commits. (i.e. our "%PART1%" test to see that paths with spaces were correctly quoted, see original commit to svn + #905, #629)

These are not local changes. The part you refer to is not even in msys-1.0.11.

the missing piece between the two antithetical sentences above are the patches I wrote and submitted to the msys bug system on sourceforge. for us as long as nothing changes and the quoting stays fixed it doesn't matter,

​http://thread.gmane.org/gmane.comp.gis.grass.devel/37771/focus=37847

My .2c:

downgrade the osgeo4w python and wxpython versions

what's the bug? news to me. ticket #?

upgrade msys and mingw

what's missing/broken in the current one? ticket #?

fix grass-addons

where/what? OSX?

anyway this one is done, let's move on.

Hamish