[SOLVED] Variable not working with shell

Something is really weird... I tried with the >>full path<< and this time I didn't add any condition value, like this:

It seems that the engine is still evaluating it
2023-11-23 02:21:55 Numeric condition failed to evaluate value “”

As soon as I added a value:
image

even though it's using one of those 6 options at the bottom, no error:
image

Go figure...

Why wouldn't it still be evaluating it? Even if the field is blank, it's going to evaluate the condition when it runs the action and then since “” is an invalid number, it is going to error.

2023-11-23 02:21:55 Numeric condition failed to evaluate value “”

Th issue you are having is that by default the shell script condition does not include any variables.

In the popup menu on the left of the script, ensure that the variable you are using is included.

Because the action is disabled. I would assume that when an action is disabled, it's the same as not being there.

I didn't know about this menu.
It is in fact, by default, set to not include variables, but I see that the Execute Shell is set to include. Is there a reason for both having a different default?
If not, wouldn't it be better that they have the same default to avoid this kind of confusion?

I just changed it to include all variables.
Same issue: all 6 options at the bottom show the error:
Numeric condition failed to evaluate “ls: : No such file or directory…”

image

If the action is disabled, then it wont be evaluating the condition.

If it is, send me an export of the macro.

If you disable the action and immediately trigger the hot key, the action will still remain enabled in the engine for a short period of time.

The defaults in different actions are different. The default for the condition is disabled because they have potentially more performance needs when they are used with loops.

Perhaps.

They are getting the error because the script is failing, giving an error/empty result, and that is not a valid number.

Post the full macro (a simplified version if necessary so other stets unrelated to this are removed), with an export. Likely there are typos in the variable name or some other issue which are very hard to debug from partial images.

Disable the action and verify that it calculates the condition even so (if it does, which I will be very very surprised at), and post that macro to. Or send it to support@stairways.com.

OMG who knows how long I've been using KM, and I had no idea that menu was there! Wow. I'd seen the carat before, of course, but just blindly assumed it collapsed the action.

-rob.

1 Like

Here's the macro.

final test.kmmacros (20.6 KB)

Limiting variables is new in Keyboard Maestro 11.

As is the ability to select modern syntax for AppleScript, which is also in that menu.

1 Like

I tried that macro, changed the path to a path I have /Users/peter/Keyboard Maestro and added Log entries on either side of the If and got the expected result (is > 5 is true, is < 5 is false).

If I removed the 5, then if does the No case and reports the failure in the log.

Numeric condition failed to evaluate value “”

Ahh, and I can see why you are seeing the error even when the condition is disabled, it is because it is being evaluated by the editor.

In fact that explains a lot of what you are seeing. With Evaluate Conditions enabled, the editor is asking the engine for the value of the condition every second, and it is reporting either that the numeric value is empty or the ls is failing (because the local variable does not exist at that point).

So pretty much all those errors are potentially irrelevant. Turn off Evaluate Condition so that the spurious errors in this case aren't happening and then see what problems are remaining.

2 Likes

After so many tests yesterday, I'm a bit lost...
I'm pretty sure that when I create this topic, the macro itself wasn't working. It was not related to the issues shown in the Engine Log.

I tested it again today and it seems to be working now.
Maybe in the beginning I couldn't make it work because of that option to include all variables, and along the way, with the Engine Log being in the conversation, that became the focus. I don't know.

So it seems that it's working now. If anything changes, I will report it.

Thank you for mentioning the Evaluate Condition option. I remember clicking it to see what that was and never turned it off. Also thank you for sharing that info about the dropdown menu.
Just a suggestion, if you would like to consider it:
Icons with arrows pointing down (or to the side) are usually seen as buttons to expand/collapse.
Maybe for menus you could use the hamburger icon to make it clearer that it is a menu.
As @griffman pointed out (and that happens to me as well), the user can be easily confused thinking that's an icon to expand/collapse whatever is next to it.
We already have the carat next on the top left corner of each action to expand/collapse, so that creates inconsistency and confusion.

I noticed that the way your text shows when using shell is different (and better) than how I see it, especially for characters such as the lowercase L.
Yours:
image

Mine (easy to think that a lowercase L is a pipe):
image

How can I change that? I thought it could be a theme issue, but turning the light theme on, doesn't change it:
image

If this is relevant, I'm on Catalina 10.15.7

Check out the "fonts" section of the hidden preferences wiki page:

https://wiki.keyboardmaestro.com/manual/Preferences#Preferences_Set_by_Command_Line

-rob.

2 Likes

@Peter and @griffman
Something along these lines, but the lines a bit thinner, similar to the current carat. I think it's more intuitive

image

Thank you so much for that link. I didn't know about it.
I was able to change that font now. Much better!

Questions, if you know this:
1 - How do I know the default fonts for each of those sections, in case I want to "undo" it?
2 - Which would be used for all fields where we can type? I want to be able to always see if I'm typing a pipe or a lowercase L.

For example I typed uppercase I, then the pipe, then lowercase L
image
Versus the new font in the Shell sections
image

defaults delete com.stairways.keyboardmaestro.editor Font-Normal

That will return to whatever the app's default setting is for the Font-Normal category.

I believe Font-Normal is the broadest one out there; I asked once about using monospace everywhere, and didn't get any replies.

-rob.

Thanks

Sorry, what I meant is which script I should use to target all text fields. I can use the Monospace, but for now only the script fields are being targeted. I was wondering which one of those lines I have to use or if there's others besides those ones?

I'm still not quite sure I understand the question. The Font-Normal will affect the most fields, but if it doesn't affect a given type of field, then I don't think you can do anything about it.

-rob.

1 Like

Sorry, I misunderstood your other reply. My bad.
I tried that line, but nothing seems to have changed, even after restarting the Engine and KM itself.

I'm using the Large option under Preferences > Text Size.
Should I have this:
defaults write com.stairways.keyboardmaestro.editor Font-Large -string "Monospace"
for example?

I don't have a lot of control over how the system displays popup menus I'm afraid.

You can under a preference setting by deleting it, so instead of:

defaults write com.stairways.keyboardmaestro.editor MouseGetCountdown -int 5

you undo it with:

defaults delete com.stairways.keyboardmaestro.editor MouseGetCountdown

Make sure you include the key otherwise it will ever so helpfully delete all the settings (not macros, but settings, which would be enough to be irritating).

It doesn't affect the basic text fields, that is a system setting.

When you say "the key", you mean for example "MouseGetCountddown", or "Font-Shell", right?

So for example if I changed the font for the Shell using
defaults write com.stairways.keyboardmaestro.editor Font-Shell -string "Monospace"

I would undo it with:
defaults delete com.stairways.keyboardmaestro.editor Font-Shell

Right?

1 Like

Yes.

-rob.

2 Likes

Thanks!