tricky application call

i need to open a xml file using an application running under X11, but piping doesn’t help.
My code:

set pt to POSIX path of ((path to applications folder as text) & "Kerkythea:Kerkythea" as text)
do shell script "open -a X11 '" & pt & "' | '~/Desktop/Kueche ky.xml'"

help is highly appreciated.


You should start with checking for X11 running in a separate step.

Your application (with UI?) should be on the menu, and then you hopefully can use UI Scripting for starting it up. Another way would be to have a special startup script for X11, that makes it run.

Then you can make the app read a named pipe, see: “The cheapest interprocess communication ever” in Code exchange, for a way to pipe data directly into your app.

I hope this helps. :slight_smile:

You can of course check if the application in question is running with ps, or System Events.

Hi MacUsr,

X11 isnt a common-environment, it is a window manager for unix applications, and it offers no toolbars for open applications. I think, its the original Terminal for Unix-like systems.
Kerkythea is the application candidate, which runs under X11 for portability reasons as i can imagine. And this app has to open an xml file. OMG.

Somebody asked me for help (and myself too) to build a script for the occasion, because some commands with X11 are a bit odd compared to the comfort of an Apple environment. Buut. i’m only a amateur using (informatic) shells, to be honest. I continue to use and understand shells, slowly only, because i’ve no programming background for it.

to make it short, i don’t know how to proceed. Also after reading your post in code exchange. Heeelp! :stuck_out_tongue:


Have you tried:
(1) changing the code you showed to directly open the file:

set pt to POSIX path of ((path to applications folder as text) & "Kerkythea:Kerkythea" as text)
do shell script "open -a '" & pt & "'~/Desktop/Kueche ky.xml'"

(2) directly invoking the app - that is what I do with ffplay…

set pt to POSIX path of ((path to applications folder as text) & "Kerkythea:Kerkythea")
log "Path is: " & pt
do shell script (pt & "'~/Desktop/Kueche ky.xml';")

In other words, with approach (2), I do exactly as I would on the command line. X11 seems to be activated by the app itself, or is otherwise transparently handled by the system.
Also, check the man page or the --help output on Kerkythea to find out the command for opening a file. ffplay can take the first argument as the file to open, but some apps may need a ‘-f myFileNameHere’ or similar arg format.

Model: PPC G4 Dual-800Mhz
AppleScript: 1.10.7
Browser: Safari 533.19.4
Operating System: Mac OS X (10.4)

Hi mhfadams
and welcome to Macscripter!
Both clues worked partially, but hope is always a great thing!
As you suggested, Kerkythea fired up X11 and Kerkythea unbolted the input file. (without to call X11, but this is a drawback for later)
Unfortunately, Kerkythea continues to process the input file, beginning to render this input file, in a single and GENERIC display window, unusual of the windows in use by the application, because a terminal window of Kerkythea itself is being invoked.

#if i do:
set kerky_pt to POSIX path of ((path to applications folder as text) & "Kerkythea:Kerkythea")
do shell script "open -a X11 '" & kerky_pt & "'"
#i get the best result. Kerkythea is running independently from a terminal window

do shell script "open '" & kerky_pt & "'"

#Kerkythea opens up a X11 term window, which is connected to the application i invoked.

#This means, if i open a file by:
set desk_pt to POSIX path of (path to desktop folder as text)
do shell script (quoted form of kerky_pt & " '" & desk_pt & "Kueche.xml';")

#.the drawn window isn't connected to Kerkythea directly, and therefore, once the command finishes its job, (job done) the only window closes (and thats a correct behavior for terminals)


Maybe there is an options somewhere about not closing the window after the command has executed?, Maybe you can circumvent it by some means. like executing whatever with an ampersand behind it, so that it really executes in the background, (that helps me sometimes). There may be other ways to circumvent the issue as well, by almost similar means. like maybe execute the program in a sub shell between parenthesis, and then have a read command at the end. Like so:

( theRealCommand ; read intoAVar )

Unfortunately, I haven’t got that program installed, and have no time to test it at the moment. I’d try theRealcommand &
first if I were you. (No semi colon.)

i did it: I tried several methods, combined with some workarounds, but this one worked:

do shell script POSIX path of app_bin & " '" & POSIX path of input_script & "'"

Now, i have following issue: when i fire up my Applescript application launcher (the above is only a piece, but THE problem piece in it), this launcher begins to hang, because of this call, till i close the invoked application binary file.
My launcher script has to quit, and not to hang!
Also the window i get is relatively little. Is there a command to expand a window (green button) from the terminal ? system events seems not to work with X11.
I begin to feel a bit frustrated. :expressionless:


Try this, the addendum, is for closing the stdin and stderr, and opening the application in the background, so the do shell script doesn’t have to “hang” for anything.

do shell script POSIX path of app_bin & " '" & POSIX path of input_script & "' 2>&1 >/dev/null & "

Hi ,
and thanks for your valuable input. Your tip does not work.this shell wants to play hard with McUsrII.
maybe i need to explain my situation a little better.

app_bin == a binary application file (in my case, this app has no terminal commands; i contacted on of the developers)
input_script == it is a script, created physically in the users temp path, who contains a string (path) to a xml file which we want to open.

do shell script POSIX path of app_bin & " '" & POSIX path of input_script & "' 2>&1 >/dev/null & "

The binary app opens the file and works without limitations, but my droplet continues to run without a reason. My droplet has no influence on the invoked binary app, because i can kill or force quit my droplet at any time.

i tried also with a separate handler, timeout and a try-routine, but nothing changes. The droplet shuts up every time i quit the binary app too.


Err… I misplaced a parameter, or messed up the order it should be entered like this:

do shell script POSIX path of app_bin & " '" & POSIX path of input_script & "' >/dev/null 2>&1  & "

What happens at the end, is that we are implicitly telling the do shell script, that there will be no output:
We redirect stdout to /dev/null, then we redirect stderr to point to whatever file the file number stdout (1) points to. then we let the command be executed by a background shell, so that the do shell script returns immediately.

I’m sorry that I didn’t do it the right way the first time. I really thought that one way was as good as the other, and I didn’t test it with a command that was suitable the first time. Sorry.

I’ll toss in an explanation why the previous attempt didn’t work: 2>&1 >/dev/null & "
Here stderr, is redirected to stdout (file handle nr 1, which points to /dev/stdout), so that the terminal handling of the do shell script sees that it will be some output, because even if stdout is redirected afterwards, stderr, still points to /dev/stdout. Those filehandles, are more like variables with a value, than a pointer, so that later redirection, of one or the other of stderr, and stdout, doesn’t update the one that are set to point to the other.

Well. The do shell script, will poll for output, if there are any, and hang until a command is finished. So we need a two part trick to circumvent this trick, in order to use AppleScript to start up something, and then just return immediately. The first part of the trick is that when the output of a unix command are redirected to /dev/null, then the do shell script knows, that there isn’t any output to wait for, and will return immediately.

The second part of the trick is to put the ampersand, at the end of the commandline, which instructs the current shell, to execute the command in another shell in the background.

You need boths parts to make the trick work.

This can be exploited (in a good way) in circumstances like Joy’s, where you want to use AppleScript to start some other process in their own shell, and let the process run independently of the “originating AppleScript” from then onwards.