[GRASS-dev] return of the OSX xterm question

GRASS GIS GRASS GIS developer
1

Messing around today, and I recalled the discussion about how to get grass-xterm-wrapper to use an OSX Terminal. I think I figured out something that could work. Combining Lorenzo's AppleScript sample and Glynn's way to strip the command out of the parameters and a little experimentation, I have a relatively simple script to do this.

Though simple - it's all handled in grass-xterm-wrapper, so there is no need to rewrite scripts - it's a bit of a messy AppleScript hack.

The main problem I couldn't fix is that the AppleScript command to run a shell script in the Terminal chokes on large command strings (1 byte over 1K), and a large string is needed to pass the env vars to the Terminal. So I pass them in byte-sized (hee hee) pieces, and there is the potential that the user can interrupt this by switching to another Terminal window.

But it's fast enough that it shouldn't be a serious problem.

To test this, replace lib/init/grass-xterm-wrapper with this one and rebuild GRASS, or replace the installed grass/etc/grass-xterm-wrapper. Before running GRASS, set GRASS_XTERM=Terminal.app in your ~/.bash_profile.

(attachments)

grass-xterm-wrapper (2.7 KB)

2

William Kyngesburye wrote:

One thing I'm wondering - is there a way to run a command in a shell
script without displaying the command in the shell? Something like
the @ prefix used in makefiles? Since I have to recreate the env
vars in the new Terminal window, a lot of stuff is spewed to the user
before the requested command is actually run.

This isn't a shell issue; it's an artifact of remote-controlling an
existing terminal through AppleScript.

Can you not just run the command in a separate terminal instance, in
the same way that xterms are used?

--
Glynn Clements <glynn@gclements.plus.com>

3

On Apr 8, 2007, at 7:00 PM, Glynn Clements wrote:

William Kyngesburye wrote:

One thing I'm wondering - is there a way to run a command in a shell
script without displaying the command in the shell? Something like
the @ prefix used in makefiles? Since I have to recreate the env
vars in the new Terminal window, a lot of stuff is spewed to the user
before the requested command is actually run.

This isn't a shell issue; it's an artifact of remote-controlling an
existing terminal through AppleScript.

Hmm. My OSX app startup does this too. I thought I've seen it purely from running a shell script in a Terminal, but I could be mistaken. Oh well, just have to put up with a little clutter...

Can you not just run the command in a separate terminal instance, in
the same way that xterms are used?

Not quite. Problems (rehash from previous discussion):

- doesn't inherit env

- returns immediately, without waiting for command to finish

- leaves Terminal as active application, so one must manually switch back to whatever called it (ie X11/Tcltk)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

4

I'll give this a try tomorrow. I don't know the answer to the question about
running a command without command output. But I'd like to know for the
wxPython GUI.

Cheers
Michael

On 4/8/07 4:41 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

Messing around today, and I recalled the discussion about how to get
grass-xterm-wrapper to use an OSX Terminal. I think I figured out
something that could work. Combining Lorenzo's AppleScript sample
and Glynn's way to strip the command out of the parameters and a
little experimentation, I have a relatively simple script to do this.

Though simple - it's all handled in grass-xterm-wrapper, so there is
no need to rewrite scripts - it's a bit of a messy AppleScript hack.

The main problem I couldn't fix is that the AppleScript command to
run a shell script in the Terminal chokes on large command strings (1
byte over 1K), and a large string is needed to pass the env vars to
the Terminal. So I pass them in byte-sized (hee hee) pieces, and
there is the potential that the user can interrupt this by switching
to another Terminal window.

But it's fast enough that it shouldn't be a serious problem.

To test this, replace lib/init/grass-xterm-wrapper with this one and
rebuild GRASS, or replace the installed grass/etc/grass-xterm-
wrapper. Before running GRASS, set GRASS_XTERM=Terminal.app in your
~/.bash_profile.

I tested it in the Tcl GUI startup mapset screen, choosing New
Location by Projection Values.

One thing I'm wondering - is there a way to run a command in a shell
script without displaying the command in the shell? Something like
the @ prefix used in makefiles? Since I have to recreate the env
vars in the new Terminal window, a lot of stuff is spewed to the user
before the requested command is actually run.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

William Kyngesburye wrote:

>> One thing I'm wondering - is there a way to run a command in a shell
>> script without displaying the command in the shell? Something like
>> the @ prefix used in makefiles? Since I have to recreate the env
>> vars in the new Terminal window, a lot of stuff is spewed to the user
>> before the requested command is actually run.
>
> This isn't a shell issue; it's an artifact of remote-controlling an
> existing terminal through AppleScript.
>
Hmm. My OSX app startup does this too. I thought I've seen it
purely from running a shell script in a Terminal, but I could be
mistaken. Oh well, just have to put up with a little clutter...

bash only echoes commands if run with the -x flag.

> Can you not just run the command in a separate terminal instance, in
> the same way that xterms are used?
>
Not quite. Problems (rehash from previous discussion):

- doesn't inherit env

So far as this part is concerned, I suggest writing out the
environment as a shell script, then sending e.g.
"source /path/to/env.sh" to the terminal, rather than sending
individual settings.

- returns immediately, without waiting for command to finish

- leaves Terminal as active application, so one must manually switch
back to whatever called it (ie X11/Tcltk)

Can you create a new terminal, send it the command, wait for the
command to complete, then kill the terminal?

Sending environment settings to an existing terminal might cause
problems for what you were doing in that terminal.

Also, isn't there anything like xterm which uses the native GUI? Or is
there something about the nature of the GUI which makes that
impossible?

--
Glynn Clements <glynn@gclements.plus.com>

6

On Apr 9, 2007, at 3:56 AM, Glynn Clements wrote:

Can you not just run the command in a separate terminal instance, in
the same way that xterms are used?

Not quite. Problems (rehash from previous discussion):

- doesn't inherit env

So far as this part is concerned, I suggest writing out the
environment as a shell script, then sending e.g.
"source /path/to/env.sh" to the terminal, rather than sending
individual settings.

Interaction with Terminal.app from AppleScript is limited to sending commands inline. If I sent the temp script file first from the shell, then switched to AppleScript control, there is the problem that I might connect to the wrong Terminal window due to the Terminal's limited AppleScript capabilities.

- returns immediately, without waiting for command to finish

- leaves Terminal as active application, so one must manually switch
back to whatever called it (ie X11/Tcltk)

Can you create a new terminal, send it the command, wait for the
command to complete, then kill the terminal?

Sending environment settings to an existing terminal might cause
problems for what you were doing in that terminal.

The AppleScript part does this. AppleScript is needed to do the waiting. It also waits for the env commands, though just with a single delay (I may need to loop that for slow Macs).

Also, isn't there anything like xterm which uses the native GUI? Or is
there something about the nature of the GUI which makes that
impossible?

I saw an alternative recently, and it claims xterm compatibility. It's in beta right now. One small problem is requiring/suggesting yet another extra on a user's system.

But mainly, I can't understand how the xterm compatibility part would work: to be able to handle the xterm flags, it has to be able to run from the CLI, but when run from the CLI an application executable opens a completely new instance of the whole application, not a new window (exactly the same problem as the browser issue I'm working on).

The open method which is necessary operates on files, and doesn't have a way to pass arguments with that.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

7

On Apr 9, 2007, at 1:26 AM, Michael Barton wrote:

I'll give this a try tomorrow. I don't know the answer to the question about
running a command without command output. But I'd like to know for the
wxPython GUI.

Do you mean echoing of the command itself to the Terminal or output from the command? I'm talking about echoing the command.

Glynn suggested that it's an AppleScript side effect, and that makes sense - AppleScript is effectively pasting the command into the Terminal window.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro

8

William Kyngesburye wrote:

> Also, isn't there anything like xterm which uses the native GUI? Or is
> there something about the nature of the GUI which makes that
> impossible?

I saw an alternative recently, and it claims xterm compatibility.
It's in beta right now. One small problem is requiring/suggesting
yet another extra on a user's system.

But mainly, I can't understand how the xterm compatibility part would
work: to be able to handle the xterm flags, it has to be able to run
from the CLI, but when run from the CLI an application executable
opens a completely new instance of the whole application, not a new
window (exactly the same problem as the browser issue I'm working on).

And what's the problem with that?

I can see why this might be a problem for a browser; I don't see why
it's a problem for a terminal.

--
Glynn Clements <glynn@gclements.plus.com>

9

On Apr 9, 2007, at 10:18 AM, Glynn Clements wrote:

But mainly, I can't understand how the xterm compatibility part would
work: to be able to handle the xterm flags, it has to be able to run
from the CLI, but when run from the CLI an application executable
opens a completely new instance of the whole application, not a new
window (exactly the same problem as the browser issue I'm working on).

And what's the problem with that?

I can see why this might be a problem for a browser; I don't see why
it's a problem for a terminal.

It's a general OSX problem/quirk when running any .app application from the CLI. If the application is already running, you don't get a new window in the application (or whatever the default action is, depending on what is passed to it). New instances of whole applications is not the way to run OSX apps.

Instead, you must tell the system to open a file with a particular application (the 'open' CLI command) so the system can take care of deciding whether the application is already running.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

10

William Kyngesburye wrote:

>> But mainly, I can't understand how the xterm compatibility part would
>> work: to be able to handle the xterm flags, it has to be able to run
>> from the CLI, but when run from the CLI an application executable
>> opens a completely new instance of the whole application, not a new
>> window (exactly the same problem as the browser issue I'm working
>> on).
>
> And what's the problem with that?
>
> I can see why this might be a problem for a browser; I don't see why
> it's a problem for a terminal.

It's a general OSX problem/quirk when running any .app application
from the CLI. If the application is already running, you don't get a
new window in the application (or whatever the default action is,
depending on what is passed to it). New instances of whole
applications is not the way to run OSX apps.

Instead, you must tell the system to open a file with a particular
application (the 'open' CLI command) so the system can take care of
deciding whether the application is already running.

That doesn't address my point.

What is the problem with having each terminal window belong to a
separate process? Or, from a different perspective, what is the
advantage to having a single process manage multiple terminal windows?

I can see some advantages for a browser, but not for a terminal.

--
Glynn Clements <glynn@gclements.plus.com>

11

On Apr 9, 2007, at 12:53 PM, Glynn Clements wrote:

It's a general OSX problem/quirk when running any .app application
from the CLI. If the application is already running, you don't get a
new window in the application (or whatever the default action is,
depending on what is passed to it). New instances of whole
applications is not the way to run OSX apps.

Instead, you must tell the system to open a file with a particular
application (the 'open' CLI command) so the system can take care of
deciding whether the application is already running.

That doesn't address my point.

What is the problem with having each terminal window belong to a
separate process? Or, from a different perspective, what is the
advantage to having a single process manage multiple terminal windows?

I can see some advantages for a browser, but not for a terminal.

Hmm. Sorry to beat this so much...

The basic OSX answer is that a single process (for an application) is the way OSX works. Though commands that are run in a Terminal window spawn their own processes.

One practical answer is that each application process (but not spawned CLI processes) shows up in the OSX Dock. All have only the name of the application, ie "Terminal".

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*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

12

I worked out how to dump the env into a script to be sourced in the Terminal window, as suggested by Glynn. This removes the lengthy output before the command is actually run (though the source command is still there). And it makes the AppleScript a little simpler.

As before, replace the installed grass /etc/grass-xterm-wrapper with this one (or replace the source /lib/init/grass-xterm-wrapper and rebuild). Also, update CVS for the latest OSX app startup (and rebuild) - I removed the hardwired xterm path.

(attachments)

grass-xterm-wrapper (79 Bytes)
grass-xterm-wrapper (3.08 KB)

13

Ah, I've been meaning to look into this more. netpbm has its own copy of the Jasper source which is built by default, and it's clashing with the UnixImageIO Jasper. I need to figure out how to disable the Jasper build in netpbm.

On Apr 17, 2007, at 1:36 PM, Agustin Diez Castillo wrote:

NetPBM gives the following error:

jas_image.c:166: error: conflicting types for 'jas_image_create'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:302: error: previous declaration of 'jas_image_create' was here
jas_image.c: In function 'jas_image_create':
jas_image.c:177: error: 'struct <anonymous>' has no member named 'colorspace_'
jas_image.c:166: error: conflicting types for 'jas_image_create'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:302: error: previous declaration of 'jas_image_create' was here
jas_image.c: In function 'jas_image_create':
jas_image.c:177: error: 'struct <anonymous>' has no member named 'colorspace_'
jas_image.c: In function 'jas_image_create0':
jas_image.c:235: error: 'struct <anonymous>' has no member named 'colorspace_'
jas_image.c:235: error: 'JAS_IMAGE_CS_UNKNOWN' undeclared (first use in this function)
jas_image.c:235: error: (Each undeclared identifier is reported only once
jas_image.c:235: error: for each function it appears in.)
jas_image.c:240: error: 'struct <anonymous>' has no member named 'iccp_'
jas_image.c:241: error: 'struct <anonymous>' has no member named 'iccplen_'
jas_image.c: In function 'jas_image_create0':
jas_image.c:235: error: 'struct <anonymous>' has no member named 'colorspace_'
jas_image.c:235: error: 'JAS_IMAGE_CS_UNKNOWN' undeclared (first use in this function)
jas_image.c:235: error: (Each undeclared identifier is reported only once
jas_image.c:235: error: for each function it appears in.)
jas_image.c:240: error: 'struct <anonymous>' has no member named 'iccp_'
jas_image.c:241: error: 'struct <anonymous>' has no member named 'iccplen_'
jas_image.c: At top level:
jas_image.c:414: error: conflicting types for 'jas_image_readcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:418: error: previous declaration of 'jas_image_readcmpt' was here
jas_image.c: At top level:
jas_image.c:414: error: conflicting types for 'jas_image_readcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:418: error: previous declaration of 'jas_image_readcmpt' was here
jas_image.c:498: error: conflicting types for 'jas_image_writecmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:423: error: previous declaration of 'jas_image_writecmpt' was here
jas_image.c:498: error: conflicting types for 'jas_image_writecmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:423: error: previous declaration of 'jas_image_writecmpt' was here
jas_image.c:577: error: conflicting types for 'jas_image_addfmt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:462: error: previous declaration of 'jas_image_addfmt' was here
jas_image.c:577: error: conflicting types for 'jas_image_addfmt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:462: error: previous declaration of 'jas_image_addfmt' was here
jas_image.c:682: error: conflicting types for 'jas_image_delcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:426: error: previous declaration of 'jas_image_delcmpt' was here
jas_image.c:698: error: conflicting types for 'jas_image_addcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:430: error: previous declaration of 'jas_image_addcmpt' was here
jas_image.c:682: error: conflicting types for 'jas_image_delcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:426: error: previous declaration of 'jas_image_delcmpt' was here
jas_image.c:698: error: conflicting types for 'jas_image_addcmpt'
/Library/Frameworks/UnixImageIO.framework/unix/include/jasper/jas_image.h:430: error: previous declaration of 'jas_image_addcmpt' was here
lipo: can't figure out the architecture type of: /var/tmp//ccvlNENX.out
make[5]: *** [jas_image.o] Error 1
make[4]: *** [base/all] Error 2
make[3]: *** [libjasper/libjasper.a] Error 2
make[2]: *** [jpeg2000/all] Error 2
make[1]: *** [other/all] Error 2
make: *** [converter/all] Error 2

__________________________________________________________
Dr. Agustín Diez Castillo
Departament de Prehistòria i Arqueologia
Fundació General Universitat de València Phone: +34 963 98 38 93
Avda. Blasco Ibañez, 28 Fax: +34 963 98 38 87
València 46010
http://www.uv.es/sidgeipa
Member of the European Network of Excellence EPOCH
http://www.epoch.eu/
__________________________________________________________

On Apr 15, 2007, at 8:57 PM, William Kyngesburye wrote:

I worked out how to dump the env into a script to be sourced in the Terminal window, as suggested by Glynn. This removes the lengthy output before the command is actually run (though the source command is still there). And it makes the AppleScript a little simpler.

As before, replace the installed grass /etc/grass-xterm-wrapper with this one (or replace the source /lib/init/grass-xterm-wrapper and rebuild). Also, update CVS for the latest OSX app startup (and rebuild) - I removed the hardwired xterm path.

<grass-xterm-wrapper>

If this works well, I'll commit it to CVS.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.