On 30 Dec 2014, at 6:52 pm, Nicola Vitacolonna <email@hidden> wrote:
AppleScript's log command does nothing of itself other than provide the logged information to the host running the script; it's up to the host what it does with it. If you add other commands to the run handler, they don't appear in Script Editor's event log either, so it's not surprising that log commands don’t.
I don’t agree. The purpose of the log command is, well, to log information, and Script Editor windows have a Messages area to display such information. It looks at least counterintuitive that log commands do not have any visible effect, especially because that happens only when scripts are run via `run script` (and only starting with Yosemite, as far as I can tell).
I think you're missing my point. Run this:
script Foo on run tell application "Finder" to get properties end run end script
run script Foo
You will see that nothing in the run handler gets logged -- my point was simply that there's nothing particularly special about the log command in this respect. If other events appeared in the event log but not the log command, *that* would be a surprise.
As far as Script Editor is concerned, there is a single event -- run script -- and that is therefore the only event that is logged. When you instead use run Foo, you're simply calling a handler, and that's an entirely different matter.
One thing I may agree with, however, is that the fact that `run script` accepts script objects is an undocumented feature (please correct me if I am wrong), so `run script Foo…` actually calls for undefined behavior.
Right. It seems to me that "run script" is shorthand for "load script" followed by calling the loaded script's run handler (OSALoadExecute or OSALoadExecuteFile). In that context, I'm not sure passing a script object makes sense; that script is already loaded. Reloading a second script object with the same name seems like it could well be problematic. But I admit I'd be more confident of that argument if it generated an error.Is there some reason you need to call run?
Well, my use case is a bunch of “task” scripts that may call each other. Think of “build” and “install”:
script build
on run argv
-- Process build options and build
end
end
script install
run script build with parameters {"--fast", "--small", "--correct"}
-- install
end
You may argue that handlers would do the job as well here, but I have simplified the context somewhat.
Then there's not much more anyone can add. I'm intrigued to know why handlers wouldn't work, but at the end of the day, what we think should or shouldn't work doesn't count for much: what matters is what does work.
Generally speaking, I think that the inability to call `run Foo` with parameters is a design flaw.
But there isn't an inability "generally speaking". There's only an inability in a particular set of circumstances, and you agree they are undocumented.
I suggest you log a bug/request, regardless. |