I just instaled the latest WinGRASS71svn through OSGeo4W (including MinGW/MSYS).
Unfortunately it uses Windows shell (CMD) instead of bourne shell (like earlier 71 installations and latest WinGRASS70beta still does (within the same OSGeo4W installation)).
Is that on purpose?
In CMD, even simple variable assignments from shell scripts do not work, and I would be missing the Unix-like environment on Windows…
2014-10-22 8:56 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:
I just instaled the latest WinGRASS71svn through OSGeo4W (including
MinGW/MSYS).
Unfortunately it uses Windows shell (CMD) instead of bourne shell (like
earlier 71 installations and latest WinGRASS70beta still does (within the
same OSGeo4W installation)).
Is that on purpose?
yes, the main reason was that we introduced bat wrappers for python
scripts. Martin
On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Martin Landa wrote:
> > Given the history of the Python issue I shall not complain about a
missing Unix shell on Windows...
>
> switching to msys shell is easy, just change in env.bat file
>
> REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> to
>
> set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> Probably we could add new item to start menu as it's in G6.
Does the Windows installer still contain MSys? If so, why?
I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.
I personally don't care much and I prefer whatever works better. (I'm not
using MS Windows, I have the real unix-like command line on my system.)
On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements
<glynn@gclements.plus.com <mailto:glynn@gclements.plus.com>> wrote:
Martin Landa wrote:
> > Given the history of the Python issue I shall not complain about a missing Unix shell on Windows...
>
> switching to msys shell is easy, just change in env.bat file
>
> REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> to
>
> set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> Probably we could add new item to start menu as it's in G6.
Does the Windows installer still contain MSys? If so, why?
I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.
I personally don't care much and I prefer whatever works better. (I'm
not using MS Windows, I have the real unix-like command line on my system.)
For me the whole idea of the last 10 years of work on getting GRASS usable on Windows was to get rid of the need of *nix emulation. Msys was the last remnant of that, and if we can get rid of it and make GRASS into a "real Windows native" than I'm all for it.
On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements
<
glynn@.plus
<mailto:
glynn@.plus
>> wrote:
Martin Landa wrote:
> > Given the history of the Python issue I shall not complain about
a missing Unix shell on Windows...
>
> switching to msys shell is easy, just change in env.bat file
>
> REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> to
>
> set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> Probably we could add new item to start menu as it's in G6.
Does the Windows installer still contain MSys? If so, why?
I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.
I personally don't care much and I prefer whatever works better. (I'm
not using MS Windows, I have the real unix-like command line on my
system.)
For me the whole idea of the last 10 years of work on getting GRASS
usable on Windows was to get rid of the need of *nix emulation. Msys was
the last remnant of that, and if we can get rid of it and make GRASS
into a "real Windows native" than I'm all for it.
Moritz
FWIW I'm in favour for keeping it.
although winGRASS is able to run without it, there are some nice and for
daily life useful gnu tools coming with msys (e.g. grep ...), IMO it
doesn't harm to ship it with winGRASS.
On Wed, Oct 22, 2014 at 8:28 PM, Glynn Clements
<
glynn@.plus
<mailto:
glynn@.plus
>> wrote:
Martin Landa wrote:
> > Given the history of the Python issue I shall not complain about
a missing Unix shell on Windows...
>
> switching to msys shell is easy, just change in env.bat file
>
> REM set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> to
>
> set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> Probably we could add new item to start menu as it's in G6.
Does the Windows installer still contain MSys? If so, why?
I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.
I personally don't care much and I prefer whatever works better. (I'm
not using MS Windows, I have the real unix-like command line on my
system.)
For me the whole idea of the last 10 years of work on getting GRASS
usable on Windows was to get rid of the need of *nix emulation. Msys was
the last remnant of that, and if we can get rid of it and make GRASS
into a "real Windows native" than I'm all for it.
Moritz
FWIW I'm in favour for keeping it.
although winGRASS is able to run without it, there are some nice and for
daily life useful gnu tools coming with msys (e.g. grep ...), IMO it
doesn't harm to ship it with winGRASS.
although winGRASS is able to run without it, there are some nice and for
daily life useful gnu tools coming with msys (e.g. grep ...), IMO it
doesn't harm to ship it with winGRASS.
I'm afraid we have an issue with what we want. Do we want to remove msys
in favor of native command line or do we want to have msys available
because it is much better then the MS Windows native command line.
Nothing stops the user from installing MSys if they want it. In fact,
users who are likely to want it may already have it installed, so we
shouldn't be installing a second copy (which may conflict with their
existing copy; even if it doesn't, they now have to configure and
maintain two copies).
We shouldn't be forcing it on people. Whether it's "better" isn't the
issue. It's not what Windows users will be familiar with. It's not
what's going to be described if users search for documentation on
"Windows command line".
GRASS 6 has to bundle MSys because GRASS 6 won't work without it. That
shouldn't be the case for GRASS 7.
On Thu, Oct 23, 2014 at 7:08 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Vaclav Petras wrote:
> I'm afraid we have an issue with what we want. Do we want to remove msys
> in favor of native command line or do we want to have msys available
> because it is much better then the MS Windows native command line.
Nothing stops the user from installing MSys if they want it. In fact,
users who are likely to want it may already have it installed, so we
shouldn't be installing a second copy (which may conflict with their
existing copy; even if it doesn't, they now have to configure and
maintain two copies).
We shouldn't be forcing it on people. Whether it's "better" isn't the
issue. It's not what Windows users will be familiar with. It's not
what's going to be described if users search for documentation on
"Windows command line".
GRASS 6 has to bundle MSys because GRASS 6 won't work without it. That
shouldn't be the case for GRASS 7.
This sounds reasonable. If users want something better then what MS
provides they should install it, as you say, or they should install
different OS or use Python for scripting, I would say.
I would also oppose adding new items to the start menu if we would come to
this. Users are confused enough from the (already) provided options.
On Thu, Oct 23, 2014 at 7:08 PM, Glynn Clements
<glynn@gclements.plus.com <mailto:glynn@gclements.plus.com>> wrote:
Vaclav Petras wrote:
> I'm afraid we have an issue with what we want. Do we want to remove msys
> in favor of native command line or do we want to have msys available
> because it is much better then the MS Windows native command line.
Nothing stops the user from installing MSys if they want it. In fact,
users who are likely to want it may already have it installed, so we
shouldn't be installing a second copy (which may conflict with their
existing copy; even if it doesn't, they now have to configure and
maintain two copies).
We shouldn't be forcing it on people. Whether it's "better" isn't the
issue. It's not what Windows users will be familiar with. It's not
what's going to be described if users search for documentation on
"Windows command line".
GRASS 6 has to bundle MSys because GRASS 6 won't work without it. That
shouldn't be the case for GRASS 7.
This sounds reasonable. If users want something better then what MS
provides they should install it, as you say, or they should install
different OS or use Python for scripting, I would say.
On Thu, Oct 23, 2014 at 7:08 PM, Glynn Clements
<
glynn@.plus
<mailto:
glynn@.plus
>> wrote:
Vaclav Petras wrote:
> I'm afraid we have an issue with what we want. Do we want to remove
msys
> in favor of native command line or do we want to have msys
available
> because it is much better then the MS Windows native command line.
Nothing stops the user from installing MSys if they want it. In fact,
users who are likely to want it may already have it installed, so we
shouldn't be installing a second copy (which may conflict with their
existing copy; even if it doesn't, they now have to configure and
maintain two copies).
We shouldn't be forcing it on people. Whether it's "better" isn't the
issue. It's not what Windows users will be familiar with. It's not
what's going to be described if users search for documentation on
"Windows command line".
GRASS 6 has to bundle MSys because GRASS 6 won't work without it.
That
shouldn't be the case for GRASS 7.
This sounds reasonable. If users want something better then what MS
provides they should install it, as you say, or they should install
different OS or use Python for scripting, I would say.
+1
Moritz
I'm still in favour to keep it.
anyway in case of not shipping msys, there are a some places needed to be
adapted in the nsis-script [1] and the package script [2].
AFAIR years ago there was some issue with the g.mkfontcap run during
installation which needed msys in %path%.
If Freetype is not installed, the font list will be limited to the set of
Hershey stroke fonts supplied with GRASS
Requiring FreeType isn't the same as requiring MSys.
The issue isn't whether FreeType is "installed", but whether GRASS was
built with FreeType support. If it was, g.mkfontcap will have a direct
dependency upon the library, and if the library isn't present,
g.mkfontcap simply won't execute. If it wasn't, g.mkfontcap will only
list the stroke fonts regardless of whether the library is present.
In this regard, FreeType is no different to any other library which
GRASS uses. If the support is enabled at build time, the library has
to be included in any Windows binary package.