Is it possible to extend the Execute_Shell_Script @ction about providing argument (with interpretation of KM tokens) an returning value from script to KM (and additional flag to set return value other than 0 as no error).
Most of classical scripts get list of arguments ($1, $2 … in shell) and returns different values to mark different results (error codes, selections …)
In current implementation I have to wrap such script in another to setup arguments from env KM_vars and change return value from script to text send to standard output.
Ive seen this:
and don’t understand why providing arguments in call of new process is not possible.
Everything is possible. But everything costs time and money. And the developer of KM is a single person, which is amazing, but means he has very limited time. I don't think he should even be reading these forums, because I'd rather see new features put into KM (perhaps like the one you've suggested.) In the post your are citing above, The Architect doesn't say it's not possible, only that he thinks it's unlikely that he will choose to do that. Everything is a choice.
If you want a new feature, it's up to you (or us) to explain to The Architect why that new feature is worth the effort. For example, what functional benefit, if any, would there be to your proposal over the existing method? Make your case. I'm all ears. I use shell scripts every day, and I'm content with (and grateful for) the method that currently exists. In fact, the original action that existed for Execute Shell Script didn't have all the features that I wanted, and I urged him to add those features, and he did! (Although I can't prove it was my words that persuaded him.)
Here is something he wrote about what kind of features he puts into KM: (which I copied from another post and pasted here)
And look at the last paragraph he wrote here: (especially the part I bolded)
Those are the criteria he uses to decide when to add a feature. If you want to win him over, the best approach is to try to meet those criteria, and not to ask "why can't a feature be added"?
Requests for new features come up so often, perhaps The Architect could write a sticky post explaining what users should say if they want him to add a new feature. Here's my attempt at such a guideline:
Explain what the new feature would do in plain language.
Explain the problem you are trying to solve, with multiple examples.
Explain why current existing features of KM don't solve this problem.
Explain the benefits to other users.
Show examples from other products that do what you are requesting.
Explain why the new feature doesn't violate the guiding principle of orthogonality.
I don't object to your idea at all. It would probably make my life easier, as passing parameters can sometimes be very tricky and even unclear. But I've mastered the trickiness, so this feature is low on my priority list. I'd rather see support for HomeKit added to KM.
I'd like to point out something that might work in your favour. Occasionally KM adds an action that isn't technically necessary. For example, in KM 5, the Screen Capture action was added. most of the features in this action were accomplishable using the existing Execute Shell Script action and calling the macOS command "screencapture". At first glance, all of the features of the KM Screen Capture action were accomplishable using the Execute Shell Script action (although it might take a second action to move the result from the system clipboard to a KM named clipboard.) So there's always hope that a redundant new action could be added.
For me, the most common shell commands that I use inside the Execute Shell Script command are probably "head" and "tail". So I would like KM to add an action that duplicates these commands' functionality. Like this: (pardon my amateur image editing skills)
But what are the chances that this will get implemented? I really haven't made my case for adding it. It may be nice, but it duplicates the existing Execute Shell Script action (which your request also does.) Duplication of functionality goes against the principle of orthogonality, which is a word The Architect uses a lot to describe his philosophy.
Here's a request that I think has a better chance of getting implemented. I'll use my template above for drafting my feature request.
Feature Request: Add HomeKit Support to KM
I want direct support for HomeKit added to KM.
I would like to be able to turn my lights on and off from within KM. I would also like to be able to detect that state of my lights, thermostats, and other sensors from within KM. I would like KM to have a trigger so that I can run a macro when a HomeKit sensor detects motion.
it is currently possible to write a KM macro to call a macOS Shortcut to control a HomeKit device, like this:
But this is a lot of effort, and there is no way I can find to "trigger" a macOS shortcut to run when a sensor detects motion, or when a temperature reaches a certain value.
Users will be able to control their smart home using Keyboard Maestro. The current level of automation inside the Home App doesn't have anywhere near the power of KM to make their home "smart."
I believe the app "HomeBridge" can do complex things like this. For reference: Install Homebridge on macOS · homebridge/homebridge Wiki · GitHub
I believe it is also possible for KM users to control HomeKit devices by getting KM to open up the "Type to Siri" window in macOS and paste a string into that window such as "turn all my lights off." But there's no viable way to fetch data or trigger on events using this interface.
Since there are no existing ways to trigger a KM macro using a HomeKit sensor's value, a new action to support HomeKit would be 100% orthogonal to existing features.
My question/suggestion arrive from my thinking about KM at all. I treat it as very good integration tool with all that twinkles and whistles like UI, triggers, OCR, user interaction etc. but ... I still need very often external programs, scripts (like shell, AS, python, JS) to do some works, which can't be done inside KM (and it is not problem for me). I write the software (but not for macOS) for last 30 years and have plenty of solutions written in Unix technologies (shell, perl, python, or C) and since switching MacOS from OS9 to Unix based OS X, all that pearls can be used without big rework here. But most of them have standard behaviour taken from Unix, where arguments provided to programs and return code received from them are key features of that environment. That is why I'm wondering why it is not implemented (I see in other tools like Alfred or BTT possibility to set arguments).
Fro other site O don't have HomeKit devices - in Europe HomeKit devices are expensive and not bought as often as in other areas, but of course I understand your point, maybe Architect will recognise it as good to implement.
It's a valid question, but remember that Keyboard Maestro executes a script, but it is not a shell itself.
It is the shell (bash/zsh/etc) that handles parsing parameters.
Keyboard Maestro executes the script by asking /bin/shto execute the script, essentially:
/bin/sh -c scriptfile
The shell has no way to pass arguments to the scriptfile directly. It could be done with positional arguments, but that would be entirely different, you would have to use $0$1 etc in your command.
An alternative would be that Keyboard Maestro could use /usr/bin/env to execute the script. But that would behave quite differently and definitely couldn't be done in a backward compatible way.
So basically, yes, it would be nice if Keyboard Maestro had some way to send in individual arguments, but for historic and implementation reasons that would require quite different behaviour. It's possibly something I'll consider doing, but it's definitely not a trivial change.
