Hmm, when I saw the xterm wrapper thread, I kinda wondered how it might affect GRASS running from a Mac Terminal. I'm not sure about the details on how the wrapper is used, but when an xterm is needed, would a Mac Terminal work?
One thing I added to my custom GRASS.app startup is a GRASS_OS_STARTUP env var. I set it to "Mac.app" and it was initially used when I added to the existing grass6 startup shell, but now I use a completely custom grass startup shell because I couldn't figure out how to pass args from the open command. I left GRASS_OS_STARTUP in the startup, so maybe grass-xterm-wrapper can use this to set GRASS_XTERM to open a Terminal instead of an xterm?
It would be kinda tricky - exec'ing a Terminal directly would actually run Terminal.app again instead of creating a new window in an already-running Terminal (not good, most Mac apps are only meant to be run once), instead it would need to be run from 'open' (this is how I start GRASS in my python startup). But this will only work to run a script from a file, not open an empty Terminal window, unless there is no window currently open.
For running a script in a new window (open doesn't need to run from exec, and returns immediately without waiting for the script to run - it's just 'opening' a file in an application):
/usr/bin/open -a Terminal some_script_file.sh
Without a script file, it just opens the Terminal, and if there is no window open, it will open a new one (what we want), but if there is already one open (there is because GRASS was started in one) it will just activate the frontmost window.
I thought about doing an inline AppleScript, but the Terminal's scriptability is surprisingly limited - there is no way to open a new window. It could be done with the System Events scripting to manually choose a menu item, but that's messy and requires a user to activate Universal Access.
If the xterm usage needs specific xterm options, then a Terminal probably won't work, since it doesn't have startup options except for running a script. Which makes me wonder - if an xterm is explicitly needed, that makes it difficult to separate the GUI from X11 if a user wanted to use Tcl/Tk Aqua (or a native Windows TclTk, if that option works).
Or, if the GUI is running in an X11 Tcl/Tk, you probably want xterms for a consistent look.
For running from the CLI, I did a search and the only place an xterm is used is r[3].mapcalculator, to run in 'expert' mode (and without grass-run.sh). That doesn't sound right - won't it be missing the GRASS running environment? Why should it run in a separate window in the first place?
Do you have a specific example of grass-xterm-wrapper use in the CLI that fails?
On Sep 4, 2006, at 2:08 PM, Michael Barton wrote:
I just discovered that the xterm wrapper script does not work for Willaim Kyngesburye’s framework build binaries for the Mac, and won’t work for Lorenzo’s binaries either in some circumstances.
The issue is that the Mac BASH terminal is used as the GRASS terminal rather than an xterm. The Mac terminal is much easier to use. But when grass-xterm-wrapper.sh is run from the BASH terminal, it doesn’t realize that x is running and returns a command not found error. This is not a problem when an xterm is launched from TclTk, which IS running in X-windows.
Solutions?
Michael
-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/
"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
- Tarzan, on war