Nice one. Thanks for sharing!
Nice plugin! But what’s the purpose of the ‘Temporary Folder’ variable?
That’s a very good question !
I took a closer look at my code, and I actually hard coded /var/tmp in some places , so there is no reason to have that field on the plugin side of things (it will just confuse some people).
I attached a new version that does not need it.
Essentially the script writes a temporary PHP file when entering raw PHP to the text box, and than it executes it, and cleans it when it is done.
PHP Script.zip (10.4 KB)
ok, this is a new version (yet again), fixed a minor bug …
PHP Script.zip (10.4 KB)
Ok, thank you for the clarification but the new version no longer works
Well, it took me a "bit" of time. I retested the script, I am not sure where the issue is.
Just in case, I will re-upload the plugin.
Also, please do not forget to run the following command on your keyboard maestro after re-applying the new plugin:
tell application "Keyboard Maestro" to reload
tell application "Keyboard Maestro Engine" to reload
It is described here: http://www.keyboardmaestro.com/documentation/6/pluginactions.html
Please let me know if you still find issues. If you do, please be specific with what you try to achieve.PHP Script.zip (9.6 KB)
Thank you very much. It works now. I probably forgot to reload Keyboard Maestro the first time. Great plugin!
Is it possible to assign the content of the system clipboard to a variable and process this one via PHP within your plugin? Or are only variables accepted that are entered via a prompt?
Yes, any variable defined in Keyboard Maestro should work with the plugin.
Did you get this sorted?
I’ve done a dump of get_defined_vars() and there is no reference in there to get the current clipboard.
How is this done?
Take a look at this example:
What I do in the example below in keyboard maestro, is to get the content of the clipboard, and assign it to a variable named "test".
In the PHP script, I am simply "echoing" the variable "$v_test".
Hopefully that makes more sense.
Let me know
I'm getting "Too Large For Environment" as output as soon as KM input variable exceeds 49 lines.
(I tested it. 49 lines will still work fine. But as soon as it's 50 lines or more, I get this error, no matter the actual content of my script - even if it's just a single "echo".)
I just tried it with very simple input (60 lines). Seems to work.
Maybe the limit is based on something else.
Is it ok for you to share the full content you try to push through, or even create some test input for me to try?
Also, where do you see the error message?
Below is the text. If I remove a single character, the output works. For instance, if I remove the "h" (last character of the last word), PHP will run.
According to https://mothereff.in/byte-counter, the breaking point seems to be 6,723 bytes. One byte more and I get "too large for environment".
Weird, isn't it?
This is the text:
test.txt.zip (1.9 KB)
I think I know what the problem is.
KM sends all variables to PHP as environment variables.
When I run the PHP command
I see the contents of all my KM variables.
And apparently, there is a maximum size that the sum of these environment variables can have:
All environment variables must live together in a single environment block, which itself has a limit of 32767 characters
It seems to me that one way to fix this would be to delete all KM vars not relevant to the current script. However, I don't want to do that, because these variables serve a purpose in other macros.
A better solution for me would be if I could run PHP and only send those variables to PHP which I actually need for the current script. I just don't know how to do that.
Update: Seems like I fixed it. Used the Macro posted here to display, sort and clear variables. Deleted variables until I was well below the 32k character count. Then it worked.
That's great, good job!
If anyone from Keyboard Maestro is monitoring, It might be a good feature to add to send only the variables the macro is using to help with this limitation ...
@peternlewis, I agree. This should apply to ALL Execute Script Actions.
IMO, it would be best to provide an option on these actions dealing with which KM Variables to send:
- Only those variables used in the Macro.
- Only those variables provided in a list
- All variables
The default could be "All variables" so that it would not break any existing Macros.
KM could actually pre-parse the script to see which of the KM variables are used in it, and only afterwards pass it on to PHP, with only those variables provided as environment variables. No human intervention needed then.
This is not true in general - is this a PHP limitation?
There is a limitation on the size of the environment variables, but it is larger than 32k.
Keyboard Maestro restricts the size of the environment variables to 100k, which is below that allowed by OS X in every version I am aware of.
Keyboard Maestro limits the size by deleting the largest variables until the size of the remaining variables fits within 100k.
So delete the variables in the script before executing php (presumaing it is a php limit).
I refer again to the Halting Problem which in general proves it is impossible to know the extent of any Turing-complete program (which includes Keyboard Maestro macros), to know whether it ever finishes, and to know what the limits are on what it might use. So any attempt I made to restrict variables to only "those used by the macros" would be inaccurate.
As far as restricting it to just the variables on a provided list, if you need less than all the variables, then delete them yourself within the script. The only case this would fail for would be if the script needed a large variable, that Keyboard Maestro had already deleted, but that could nonetheless fit within the environment if other smaller variables were deleted - and frankly this is such a limited use case as to be not worth handling.
If you really need a large variable passed to a script, write it to a file, and read it in the script.
No, it really could not. Not accurately or correctly in the general case - it is impossible (not just difficult, but actually proved to be impossible).
Implementing difficult things is something I try to avoid, but I will do it on occasion. Implementing impossible things I draw the line at.