[SOLVED] Shell script not working with KM, but works with Terminal

Yes, I installed it today I can normalize the files via Terminal

@noisneil, do you know why KM's Execute Shell script action doesn't run .zshrc?

Yes, adding that extra line to the action made it work
export PATH="/opt/anaconda3/bin:$PATH"
/opt/anaconda3/bin/ffmpeg-normalize "/Users/dannywyatt/My Files/Inbox Global/Danny Wyatt - Cookies.mp3" -f -c:a libmp3lame -b:a 320k -nt peak -t -1 --output "/Users/dannywyatt/My Files/Inbox Global/Danny Wyatt - Cookies normalized.mp3"

Is it bad that I have it like that?
I mean, it's working now...
That doesn't mess with any other files or anything, right?

Hooray! I was right all along. My solution is fine. It won't hurt a thing. I was just trying desperately to give you a "more right" and easier solution.

But ultimately this is a flaw in your product and/or its init program which is supposed to set up your .zshrc file for macOS, and it isn't working.

There's a chance that something else will also be broken. We fixed it for one program, but others could also be broken for similar or different reasons. But this fix is a standard fix that I've had to do a dozen times in my past.

1 Like

I don't but ChatGPT thinks it does:

"Interactive configuration files like .zshrc are only read by interactive shells, and .bash_profile, .profile, or .zlogin are read by login shells. When a shell script is executed from within an automation tool, it's usually run in a non-interactive, non-login shell, which doesn't read these files by default.

If you need to execute something that is defined in your .zshrc file, you can source the file at the beginning of your script manually. Here's an example of how you might do that:

source ~/.zshrc
# ... rest of your script ...

However, be cautious when doing this, as .zshrc can contain interactive elements that don't make sense in a script context and might cause errors or unexpected behavior.

It's usually better to explicitly define any environment variables or paths directly in your script or use a separate configuration file that contains only the necessary components for your script to run."

Wow. Chat GPT is talented in this topic, and probably right. I forgot those details. I also don't use ChatGPT much to solve my problems. I know it's the future.

As long as it works and it doesn't mess with other files, I'm totally ok with having an extra line :slight_smile:

Ok now back to the initial problem (remember the double quotes, etc, @noisneil?)

Here's the original script with the FOR EACH action using the variable Local__mp3:
export PATH="/opt/anaconda3/bin:$PATH"
/opt/anaconda3/bin/ffmpeg-normalize "$KMVAR_Local__mp3" -f -c:a libmp3lame -b:a 320k -nt peak -t -1 --output "$KMVAR_Local__mp3 - normalized"

The reason it wasn't working is because when we use "$KMVAR_Local__mp3", it's using the full path including the extension, in this case .mp3
So when I use "$KMVAR_Local__mp3 - normalized" the final result is something like this:
"Danny Wyatt - Cookies.mp3 - normalized"

The solution for this is to first remove the extension from the variable and then adding it manually in the script

image

I tested it and it's working.
I noticed it by accident in the engine logs:

1 Like

I have no clue what that all means, what you just pasted, but I guess that this quote right here is what @Airy suggested, right? So I'm good with that workaround?

KM also has an ENV_PATH variable, where you can set your regularly used paths (just like you do in your .bashrc or .zshrc file). This saves you from prepending the paths to your binaries in each script action:

Edit: Fixed the Wiki link.

Now that we fixed the problem, I started looking at your KM code. I think I understnad it. But let me mention an alternative. Instead of removing ".mp3" you can use a filter action like this:

image

The reason the Filter action is better is because it's more reliable. For example, if the file had the name "/aa/bb/cc/AbbaMusic.mp3x" then your code would fail but the Filter would have worked.

1 Like

Wow, that's news to me. However your wiki link is broken, here it is, corrected:

https://wiki.keyboardmaestro.com/action/Execute_a_Shell_Script

The actual relevant part is in a section called "Path in Shell Scripts"

Awesome. Tried the filter and it's working.
It makes perfect sense. And I can use that to another macro where I'm doing the same thing.
Thanks!

So is your first workaround still the way to go or should I use something else now that you have more info on the subject?

Thanks. This is the link wanted to post above (It's fixed in the post):

Path in Shell Scripts

My first workaround, which was almost working, and might still work with another 10 minutes of investment, would save you from typing that one line. But really, with either workaround, the problem is that the app wasn't setting up your environment correctly. We could keep patching bugs (there may be more) or you could contact the company or visit their technical website to try to find the workaround/fix.

Tom suggested using a certain variable to load the path into, rather than adding the line to each action. Yes, that's a pretty cool idea that I didn't know about. You could read that section. But to save you the effort, you can just do what's working now.

Sorry, when I said "your first workaround" I was talking about adding that line to the script itself, not the workaround of changing that other hidden file.
So to be clear:
Your first workaround is the extra line at the top of the script
The "second" workaround was the one that @Tom mentioned.

So I was wondering if using that extra line is enough or if in that wiki article you found something else that would make more sense?

Again, it's working now and if you think it's more than enough and doesn't mess with anything else, I'm totally ok with it. I was just wondering if that wiki article had something that would be more reliable, or something like that?

If not, I guess we can all take a break from this :slight_smile:
I appreciate you all for your time and help on this! :muscle:

Yes.

I think you don't use this fix often enough to merit learning about the new feature in that link. It's just another way to skin the same cat, and the way you have now is enough for you, I believe.

If you're referring to the path environment variable (ENV_PATH), then I'd say yes, it's more reliable in the sense that once it's set correctly, you're protected against wrong paths or typos in paths that might occur when you add the paths to your script actions each time.

1 Like

Sorry for the long delay...
Today I was facing a similar issue with another command line and I was doing some more research, while another member helped me set the ENV_PATH up, along with some more clarification.

I think I now understand how the ENV_PATH works and how it makes it way easier and faster to work with command lines in KM.

Appreciate your help!

1 Like

I would even say it is an essential part of a working KM setup :wink:

1 Like