Jim Wintermyre writes:
> I tried doing something very similar to the listing below, but I
> still can't get it to work. I'm hoping I'm just being dense and one
> of you guys can help me out. I created a test shell script, and put
> it at /usr/bin/test, and ran chmod 755 on it. Line endings are unix.
> I can run ./test in the terminal and the script runs as expected.
> The script itself looks like this:
>
> echo "This is a test"
> open /Applications/TextEdit.app
>
> In my driver's user client, when I get the client died message, I do this:
>
> kern_return_t result;
> result = KUNCExecute("/usr/bin/test", kOpenAppAsRoot,
kOpenApplicationPath);
>
> If I then kill one of my client apps, I do get the client died
> message (which I log to the console right before the KUNCExecute
> call), but the script doesn't appear to be running. I don't see the
> text output, and TextEdit doesn't launch.
>
> Is there anything obvious that I'm doing wrong here?
To be a valid shell script, it needs to begin with shell magic, which
is #![interpreter-path]. Eg, #!/bin/sh.
I'm pretty sure that when you exec something from a shell, it first
tries to exec() it, then if that fails (like because there is no shell
magic at the start), it tries to source the file.
From ktrace, when script foo has no magic:
248 sh CALL execve(0x30b730,0x30b8d0,0x30b790)
248 sh NAMI "./foo"
248 sh RET execve -1 errno 8 Exec format error
248 sh CALL open(0x30b730,0,0x30b790)
248 sh NAMI "./foo"
248 sh RET open 3
From ktrace, when script foo has magic:
255 sh CALL execve(0x30b740,0x30b8e0,0x30b7a0)
255 sh NAMI "./foo"
255 sh NAMI "/bin/sh"
255 sh NAMI "/usr/lib/dyld"
255 sh RET execve 0
Since KUNCExecute() is not a shell, a failure from exec() would stop
it, and the script would not execute.
Also, I don't think that stdout is connected to anything in the
KUNCExecute() environment, so I would not expect to see
"This is a test" show up anywhere. Try redirecting it
to a file (> /tmp/foo). That's how I debugged my script.
Lastly, at the risk of sounding pedantic, its always a bad idea to
name an executable "test" -- there is a /bin/test program which is
integral to the functioning of nearly all shell scripts. You want to
make sure you don't override or clobber it ;)
Drew
