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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
