Error in ExecuteScript

[Creeky]

I admit it: there was confusion on my part . I should should have put my scripts in ~Library/Application Support/SqueezeCenter/scripts, whereas I was actually putting them in ~Library/Application Support/SqueezeCenter. The displaying on the web page of which scripts folder executescript is looking at is very useful for the confused!

The scripts now display fine as options, and I've turned on debugging for the executescript. I can see that the executescript claims to be running the relevent script files on each event. However, the script file does not actually seem to run.

To test this with a simple script, I created a script file "test.sh" in the scripts directory, wired it up to the open event in the executescript plugin settings page, and played a track. The log indicates executescript claimed to run the script file, which had read/write/execute permissions for all users, and contained the following:

#!/bin/bash
/bin/echo "test" > /tmp/test.log

However, the test.log file is never created.

The log contains the following:
[08-01-23 23:03:46.8663] Plugins::ExecuteScript::Plugin::commandCallbackOpe n (265) Execute: File Open
[08-01-23 23:03:46.8670] Plugins::ExecuteScript::Plugin::commandCallbackOpe n (274) using server pref
[08-01-23 23:03:46.8673] Plugins::ExecuteScript::Plugin::commandCallbackOpe n (279) Execute: Executing test.sh

I used the executescript you attached in your previous post.
Thanks for your continued patience

[kdf]

On 23-Jan-08, at 3:08 PM, Creeky wrote:

> However, the script
> file does not actually seem to run.

There is nothing whatsoever that is fancy about this part. If you see
the log message that the script is being called, then it gets called.
It's a simple system call that sys "execute this filename" and the os
is expected to take over from there.

There isn't much else that can be done from the plugin side of
things. The script must be executable by the slimserver/squeezecenter
user, and in this case also have create/write permissions in /tmp. I
personally don't know what user realm is used for the osx dmg install
version, and I tend remain blissfully unaware of the deeper darker
internals of osx itself.

I'd start simple, with a script that does just an echo to stdout.
Then run the server manually from the terminal:
/Library/PreferencePanes/SqueezeCenter.prefPane/Contents/server/
slimserver.pl

This is what I did for my own test, and that should work. In this
case, as long as the script can be run by you, then the plugin will do
the same since it runs with your permissions.

-kdf

[Creeky]

Sorry, was on vacation last week, but i've now tried your suggestions, kdf.

I ran slimserver.pl from a terminal session, and checked the access time of the script that should be being run (i.e. the one that executescript logging says it is running on open file).

The script just echos a message to stdout. No message is displayed. I used stat to check the last access time of the script file, and the access time is not updated by executescript. If i run the script from the command line the access time is updated.

It would seem that for some reason executescript is not executing the file. I double checked the permissions, and the script file is in a directory with rwx permissions for all users, and the script file has the same permissions. Typing 'ps -j' indicates that the slimserver perl process is running under my user account (the same one i can use to successfully run the script manually). I can't see why executescript shouldn't be able to run this script file, but it does not appear to be.

[kdf]

Sorry, there isn't much more I can suggest. I've tried it here, and
it does work. If you see the debug saying the script is being called,
then it is called and I'm out of ideas as to why nothing happens on
your setup.
-kdf

[Creeky]

I have one more idea...

I've been looking through the source to plugin.pl and see that the perl command you're using is "system $runScriptPath;"

I believe $runScriptPath on my system would contain
"/Users/<username>/Library/Application Support/SqueezeCenter/scripts"

Could the space in "Application Support" be causing a problem?

[kdf]

<3E610738-3DC6-4D34-869C-8468F56263B4 (AT) deane-freeman (DOT) com><Creeky.347ken1202047801 (AT) no-mx (DOT) forums.slimdevices.com> <5FFE3F03-E356-4627-8F68-7560D2AD6E86 (AT) deane-freeman (DOT) com> <Creeky.3484jn1202073902 (AT) no-mx (DOT) forums.slimdevices.com>
X-Mailer: Apple Mail (2.915)


On 3-Feb-08, at 1:23 PM, Creeky wrote:
>
> Could the space in "Application Support" be causing a problem?

Then try:
system "$runScriptPath";

Something like this was done before as I recall, but caused other
problems, so unfortunately it would have to stay as a local mod if it
works for you.

-kdf

[kdf]

I've posted a new version to googlecode that fixes spaces so that they should work for osx and unix.
-kdf

[Creeky]

It's definitely the space in the directory path that is causing the problem. For my own local fix I found that hard coding the value returned by scriptPath() to /scripts and putting my script files in there worked fine. Double quoting (system "$runScriptPath") didn't work. I get the impression the quotes get stripped before they reach the shell.

Thanks for your continuing work on this. Unfortunately the new code you posted doesn't quite solve the problem with the space character. Escaping the space with a backslash works for the system command, but fails on the readDirectory command in scriptList() (line 183 in Plugin.pm). Because of this no script files get listed in the settings web page.

To get around this, I created two scriptPath() subroutines; one - scriptPath() - doesn't do anything to escape spaces on unix, and the other - scriptPathSpecial() - does. I then altered the code so that scriptPath() is called by scriptList(), and scriptPathSpecial is called by the four sub CommandCallbackX subroutines.

I'm not quite sure when 'play' => sub {...} (line 139) is called, so didn't test it, but I suspect that would also need to use scriptPathSpecial() rather than scriptPath().

----------------------------------
sub scriptPath {
my $scriptPath = catfile((Slim::Utils::Prefs::dir() || Slim::Utils::OSDetect::dirsFor('prefs')),'scripts' );

return $scriptPath;
}

sub scriptPathSpecial {
my $scriptPath = catfile((Slim::Utils::Prefs::dir() || Slim::Utils::OSDetect::dirsFor('prefs')),'scripts' );

if (Slim::Utils::OSDetect::OS ne 'win') { $scriptPath =~ s/ /\\ /g };

return $scriptPath;
}
---------------------------------

[kdf]

Looks like it will have to be at each system call, after all. Never
know when the script filename itself will also have spaces.
I'll post a newer version hopefully later today after I've tested a
solution for windows as well.
-kdf