Bug Report: KBM 11.0.2 Filters Don't Remove Extension from Pathname

I have found two filters that do not behave as expected: Base Name/Basename and Delete Path Extension.

According to the doc for the Basename filter (note that it is misspelled in the KBM UI and if you search the doc for "Base Name", as it's called in the UI list in the Filter action, you won't find anything) using that filter should remove the file name extension. So should the Delete Path Extension.

But if the filename has a space before the extension (tested with [space].txt and [space].rtf), then the extension is not removed.

I can work around this, but it's not the expected behavior. The OS (Finder) recognizes the files as their type by the extension, despite there being a space in the filename, and it opens them with the appropropriate app. The space does not give Finder a problem, and it shouldn't bother KBM either. (IMHO)

I find that if I create such a file at the Terminal prompt:

cd ~/Desktop
touch alpha\ .txt

I can both see it in the Finder:
Screenshot 2024-01-29 at 8.00.47 am

and derive its Base Name (extension pruned) with the filter action:

As there are various textual representations of file paths (+/- quoted, +/- escaped, +/- tilde expanded, etc etc), this kind of filter inevitably needs to be defined over a standardized representation.

Fortunately, you can prepare your filepath for a filter by standardizing it first (using Keyboard Maestro's Standardize Path filter):

Extension dropped from standardized path.kmmacros (3.6 KB)

The Base Name filter will take a file path and return just the name part, excluding the path and excluding the extension.

The Delete Path Extension will take a file path and return the file path with the extension removed.


File Path is “~/Folder/Whatever .txt”
Base Name is “Whatever ”
Path Without Extension is “~/Folder/Whatever ”

I'm not sure what you mean is misspelled. Basename is not really a word and probably should never be used.

This is not the case, so I'm not sure what it going on for you.

I agree. And it doesn’t.

You generally should not use \ to quote spaces in Keyboard Maestro paths.


I think most of these confusions about the relationship between an actual Path and a textual representation of it are well fixed by the Keyboard Maestro Standardize Path filter.

( or in the context of Execute AppleScript and Execute JavaScript for Automation actions, the equivalent string function )


Expand disclosure triangle to view JS source
// filePath :: String -> FilePath
const filePath = s =>
    // The given file path with any tilde expanded
    // to the full user directory path.
filePath("~/Desktop/alpha .txt")


Expand disclosure triangle to view AppleScript source
use framework "Foundation"

-- filePath :: String -> FilePath
on filePath(s)
	((current application's ¬
		NSString's stringWithString:s)'s ¬
		stringByStandardizingPath()) as string
end filePath

filePath("~/Desktop/alpha .txt")
1 Like

The behavior was pretty consistent and I tried lots of Display Text In Window actions before and after to verify what was happening.

AND I figured it out.

The filename is generated by an Execute Shell Script action and the script returns two values, separated by a newline. I was attempting to apply the Base Name filter to the extracted variable value, not just a filename. So I suspect that

would indeed fix it.

1 Like

"Base Name" is the label for the filter choice in the UI. "Base Name" does not appear in the User Manual or Wiki, but "basename" does. The command basename is a standard UNIX command and can be used in MacOS from a terminal or Shell script, which is probably why it made it into the Manual that way.

Whatever you think the proper spelling should be is fine with me, two words or the UNIX command, I don't care. My concern is that the UI says "Base Name" and I when I search for an explanation of what that filter does, I cannot find "Base Name" in the Manual or the Wiki. That, to me, is an error, whether you call it a misspelling, a typo, an omission, or whatever, I don't care. It's an error because it's confusing and does not help the user find the info they need.


Yes, I have corrected the wiki.


Thanks. Sorry for going all pedantic on you.


Why? I like pedantic. Things should be consistent.