It is quite possible to initialize and run grass without Bash. I have a simi-working python script that fires up GRASS using IPython as it's shell. In fact, since Python abstracts os calls such as creating temp files, setting environment variables, etc, it is actually much easier to write a cross-platform initialization script in Python than in Bash. HOWEVER (and this is big), if you do not have a traditional unix shell running grass, none of the nearly 100 or so scripts that are distributed with GRASS---and that depend on bash---will work.
<br><br>Many standard GRASS commands are really shell scripts. Every single one of them will need to be ported to your new shell if this isn't compatible with Bash. I stopped working on this when I realized how disruptive this was going to be (and how unlikely this would be supported by the core GRASS community). I don't think the vast majority of GRASS developers want to move to a Python environment (or Ruby or Perl or
cmd.exe, etc). So, basically, this is an idea dead-on-arrival. It would amount to a fork of GRASS and new users would have a terrible time figuring out which shell they were supposed to be using for each script.<br><br>I think that GRASS is intimately tied to a Posix-compliant shell. There needs to be a standard macro-language for scripting and Bash seems as good as any.
<br><br>David<br><br><br><br><div><span class="gmail_quote">On 8/11/06, <b class="gmail_sendername">Trevor Wiens</b> <<a href="mailto:twiens@interbaun.com">twiens@interbaun.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 11 Aug 2006 11:19:48 -0500<br>William Kyngesburye <<a href="mailto:woklist@kyngchaos.com">woklist@kyngchaos.com</a>> wrote:<br><br>> I've been working on an alternative Mac GRASS.app startup - currently<br>
> it uses the OnMyCommand droplet as an app template, but I'm looking<br>> for a more open source, buildable kind of startup, and found py2app.<br>> (Lorenzo's AppleScript Studio method could work, but I don't want to
<br>> have to deal with Xcode.)<br>><br>> I have something that works, but it got me thinking about the<br>> wxpython gui developments. I haven't been paying much attention to<br>> that and haven't had a chance to try it yet. So, py2app offers a
<br>> cool possibility - a completely selfcontained Mac application, and<br>> its cousin py2exe might do the same for Windows.<br>><br>> My question is, does, or is it possible in the future for, wxpython<br>> grass to start directly from python?
<br><br>This is a good question and there has been some off list discussion<br>about this. What I've researched and am (very slowly implementing) is a<br>way to wrap the shell within the python GUI (optionally) so that users
<br>will be able to use the shell of their choice with the new GUI.<br>Obviously a python shell would be default, but bash, etc would be<br>available. Together with this I'm planning on building a socket based<br>interface to the display tree that will be callable with a few simple
<br>commands from whichever shell the user chooses. The advantage over the<br>existing display architecture is that it will be possible to manipulate<br>the display layers and redisplay from command line without having to
<br>reissue each draw command. Another advantage is that the command line<br>use and the GUI are synchronized. One of the strengths of the new<br>gis.m is that you can have different views of the same data in<br>different windows but the difficulty for CLI based users is that
<br>one can't EASILY manipulate those views from CLI. I'm trying to solve<br>this problem as well as make CLI use more elegant and GUI programming<br>simpler. At this point nothing is implemented as I'm in the research<br>
and planning stage.<br><br>> Or like the tcltk GUI, does it<br>> need the GRASS shell running first for the initial environment<br>> setup? It would be nice for the wxpython GUI to setup and maintain<br>> the environment that
init.sh does. Then it could let the user open a<br>> Terminal or other shell (maybe a pseudo-terminal within python?) to<br>> run commands the old fashioned way if desired, but not require that.<br>> Also, it would keep a persistent '
GRASS.app' application in the Dock<br>> while 'GRASS' is running.<br>><br>> My current python startup app just fires up the normal init.sh<br>> startup and quits, leaving GRASS running in the Terminal and the GUI
<br>> in TclTk X11, and disappears from the Dock. While the OnMyCommand<br>> method at least stays around in the Dock until GRASS is quit from the<br>> Terminal (even tho it doesn't do anything after starting GRASS, it's
<br>> nice to have that visual clue in the Dock that GRASS is running).<br>><br>> Another question about the wxpython GUI - does or will it handle<br>> multiple GRASS sessions at once, kind of like having multiple
<br>> documents (ie mapsets) open in an application?<br><br>>From my point of view, this idea conflicts with GRASS architecture.<br>Still, if for Mac users running multiple instances was desirable but<br>problematic as the application wouldn't be shell dependent, it would
<br>be possible to program the facility to open another copy of the GUI for<br>another mapset. Hmmm... Perhaps it might be useful to think of what<br>functionality this would achieve and then think if there is a more<br>
elegant solution, such as gis layer (not in the convoluted vector<br>terminology sense) file browser which would enable one to look at<br>other mapsets, etc. Associated with such a GUI tool would obviously<br>come copying and reprojection, but since I'm not sure what you are
<br>thinking of, this idea may be way off base.<br><br>> A Mac application<br>> normally can only open in one instance, unlike running different<br>> instances from multiple Terminal windows. I just realized that my
<br>> current OMC app can only run one at a time, since the app stays open,<br>> yet the python method I'm working on can open multiple instances of<br>> GRASS, since the app itself quits right away, leaving GRASS running
<br>> (a bit confusing for a Mac user, and especially so since there is no<br>> hard connection between the GUI and the Terminal shell that opened it).<br>><br>> One nice thing about the py2app setup is that it can locate and
<br>> create local copies of all dependencies (python modules and dynamic<br>> libraries and frameworks) needed plus a minimal copy of the python<br>> runtime environment. Then the user doesn't have to worry about which
<br>> Python they have installed, that might be too old or too new, or<br>> having all the needed modules installed. With the current init.sh<br>> startup, it would have a hard time locating dependencies for this
<br>> since it doesn't really 'see' the internals of the wxpython grass<br>> gui, though it might since it seems to be pretty rigourous in<br>> identifying stuff like that.<br>><br>> -----<br>> William Kyngesburye <
<a href="mailto:kyngchaos@kyngchaos.com">kyngchaos@kyngchaos.com</a>><br>> <a href="http://www.kyngchaos.com/">http://www.kyngchaos.com/</a><br><br>T<br>--<br>Trevor Wiens<br><a href="mailto:twiens@interbaun.com">twiens@interbaun.com
</a><br><br>The significant problems that we face cannot be solved at the same<br>level of thinking we were at when we created them.<br>(Albert Einstein)<br><br>_______________________________________________<br>grass-dev mailing list
<br><a href="mailto:grass-dev@grass.itc.it">grass-dev@grass.itc.it</a><br><a href="http://grass.itc.it/mailman/listinfo/grass-dev">http://grass.itc.it/mailman/listinfo/grass-dev</a><br></blockquote></div><br><br clear="all">
<br>-- <br>David Finlayson