Re: Interacting with external shell scripts
Re: Interacting with external shell scripts
- Subject: Re: Interacting with external shell scripts
- From: "Mark J. Reed" <email@hidden>
- Date: Mon, 11 May 2009 15:31:09 -0400
On Mon, May 11, 2009 at 2:23 PM, Anthony Adachi <email@hidden> wrote:
> Is that the limit of interaction possibilities with a external shell
> script from within a AppleScript Applet? Nothing beyond simply invoking
> the whole shell script via "do shell script" and getting it's last result?
Right. There's no back and forth built in. You can go through some
complex motions to set up a script that runs in the background and
listens for requests via some communications channel, and then run
commands to make those requests, but there's nothing in the standard
AS/Shell interface to handle that.
> 1. Whether or not there are any ways for an AppleScript Applet to talk
> to a external shell script as it might with a Stay Open Applet?
Nope. The closest POSIX analog to that would be opening a command via
popen() and then reading its stdout and stderr while writing to its
stdin, but AS doesn't support that.
> 2. Or whether it's possible for an AppleScript Applet to call specific
> functions within a shell script as it might do if it loaded a
> AppleScript library and calling specific methods within that library?
No. Shell script functions are only callable from the shell, and only
from the specific shell instance where defined.
> File system changes such as these?...
File system changes such as any. Shell commands can read files, write
files, delete files, create directory trees, whatever. The point is
that
do shell script "cd /some/directory"
followed by
do shell script "pwd"
does not yield "/some/directory". The first shell exited after the cd
command, rendering it useless; this is why "cd" has to be a shell
builtin (there's no /bin/cd, because executing it would be a no-op).
Similarly, any other side effects of the first command that only live
within the shell environment, like the current working dir, are lost.
So it has to write something to a file somewhere to have a lasting
impact.
> Like this?...
>
> do shell script "source path_to_shell_script_function_lib.sh;
> do_useful_things_func; do_stuff_func"
Yes, like that.
> Does this mean that one cannot load/source an external shell script
> function library only once? In other words, one needs to source it/read
> it multiple times from disk throughout the life of the AppleScript
> Applet, each time one wishes to invoke the desired functions?
It needs to be loaded once *per shell* and every 'do shell script'
command launches a new shell. So yes.
> I was thinking more along the lines of loading libraries of defined
> functions one finds useful. i.e.- code reuse.
Shell scripts are the standard unit of code reuse for the shell. You
might break things out into functions *inside* the script for ease of
maintaining the code, but there's no way to access such functions from
outside the script (unless you source it, in which case you identify
the script and the calling shell and probably terminate the latter
because most scripts are designed to exit at the end). In general, if
you have an "API" with disjoint entry points, you provide a separate
script for each one. That is, unless there is some shared state kept
inside the shell environment (in a set of variables, say), in which
case you provide a suite of functions that interact with each other
and must therefore all be called from within a single shell. For
instance, I have a suite of shell functions that maintain a history of
my current working directories, in a manner more flexible than
pushd/popd/dirs (starting with the fact that I don't have to remember
to pushd, I just cd).=
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden