Hi, @TomMxEdit. Now that I understand your objective, here's the approach I would take.
Download: Rename Folder Files Using a Model Folder.kmmacros (53 KB)
In the macro header comment, you'll see this note:
Hi Chris,
That is a fantastic solution! It works nearly instantaneously and will be the way I change these names going forward.
I’ll study it some more as I go along to understand exactly how it works.
It’s much more elegant than my solution, which was basically to have the macro type the return key to select the name of the file, command-C to copy the name and then click a screen location to select the target folder. Then another return to select the destination file name, command-V to paste, arrow down, wash, rinse repeat. Entertaining to watch it progress, but somewhat slow in the execution.
Thanks for taking the time to program this! It will be a huge time saver.
Tom
Hi Jim,
Thanks for the macro! I wasn’t able to progress past the OK button. As you say, by clicking on the button, you exit the macro. How would you continue stepping forward without clicking that OK? In other words, how does one enter nothing? I’m sure it’s quite simple, but I’m not seeing it right now.
Thanks again,
Tom
Hi, @TomMxEdit. I suspect you had the Finder windows open but then triggered the macro using the Keyboard Maestro Editor. When you do that, the Finder window is no longer in the foreground. If you had left the Finder window in the foreground and triggered the macro with a hot key, you would have seen a different dialog.
I just uploaded a revised version of the macro that presents different options when this scenario occurs.
Regardless, if you try the revised macro you will see that you now have two good options (@ccstone's and this one). One difference, however, is that my macro will present at least one dialog each time you run it. (It will direct you to open the destination folder.) That may be a pro or con. On the plus side, you can have as many Finder windows open as you want. In fact you can have just one with the source is one tab, and the destination in another. I like the approach of guiding use, particularly if it's with a macro that might sit dormant for weeks and then I come back later and try to use it.
If you have everything set up correctly before running @ccstone's macro, it will work great! If my memory serves me correctly, he's not a big fan of dialogs. (He's trying hard to not make fun of the approach I used. 
I kid; if fact @ccstone saw my macro and gave me a tip to improve it. As you probably know, he's an incredible resource–and a great dude!!)
Here's a short video that shows the macro flow. Two dialogs appear because the Finder is not in the foreground when the macro was triggered.
Hi Jim,
You are correct, Sir! I was running it from inside KM. I’ve now tried it out as designed — from within Finder — and it works as advertised. Another good solution from a different angle and I suppose a bit more idiot-proof, which in my case could come in handy!
Thanks for the revision and the explanation,
Tom
That macro is just basic AppleScript, except where I use AppleScriptObjC to perform the sort.
You have to use AppleScript to get the targets of Finder Window 01, and Finder Window 02 in a "simple" automated fashion.
The FinderInsertionLocation text-token uses AppleScript behind the scenes to get the path of the frontmost Finder window (or the Desktop if no other accessible window is open).
And of course you can use the Prompt for File action to painfully, and slowly select files or folders.
In general I prefer to set things up just so in the Finder and then run a macro that does all the other work, and I have a bunch of Finder macros to make this easier and reduce the likelihood of error.
The appended macro uses AppleScript only to acquire the PATHs for Finder Window 01 (source names) and Finder Window 02 (items to be renamed), and it uses Keyboard Maestro native actions to do everything else.
I've added some extra error-handling to this macro to attempt to make sure the user has the correct windows on the left and right and that their indexes (front-to-back) are correct.
In any case – you now have a model for performing this task with mostly Keyboard Maestro native actions.
Download: Rename Files in Right-Hand Folder from Left-Hand Folder (KM) v1.00.kmmacros (16 KB)
Excellent and works equally quickly. Thanks for the update!
Tom
This is why when asking for help on the forum users should always give an overview of what they're trying to do.
It saves everyone time.
When we know what a user is trying to do we can frequently offer methods superior to what they're attempting (if and when we have a deeper understanding of the capabilities of Keyboard Maestro).
Point taken, Chris…
A slight question with your macro, Chris:
In a case where the source file name and the destination file name are the same except the case varies in a letter or two between the source and destination, I’m finding the case doesn’t change in the destination. In other words, it almost seems to ignore case differences. For instance if the source is
16 Old Granddaddy.wav and the destination is
16 Old granddaddy.wav the destination does not change case.
In fact this second file with the small "g" is a copy after the macro was run. Is there a check of some type that says not to paste if the file name is the same, ignoring case differences? Or would that possibly be a Mac OS autocorrect feature? It seems pretty consistent when all else is the same. If there are any changes other than the case in the file name, then it pastes the name exactly, with the correct case.
Tiny issue and easy to spot and correct in any case.
Thanks and I’m really enjoying the macro!
Tom
You're using the KM version?
The AppleScript version correctly handles case-change-only renaming.
A pure shell script mv also correctly handles case-change-only renaming.
It would appear that the native move-action in the KM version does not see a case-change as a legitimate change...
The problem is easy enough to work around, but perhaps it's something Peter can fix.
Yes, that is correct: I’m using the KM version.
Thanks for looking at it and explaining that.
Tom
Okay, this one is on me! I think I see what the problem is: The destination files are on a thumb drive formatted as Microsoft NTFS. I just noticed that even if I change the case in the file name manually, it reverts back to the original case. For instance, changing the word “Of” to “of” reverts back to “Of” after committing the change by hitting enter. It will stick if I change it a couple of times, but the first time (as a paste would be) changes right back to whatever the case was originally. Odd…
Tom
The problem occurs with two folders on my internal APFS drive, so your issue with the NTFS and the thumb drive is not the only one.
Okay, thanks for that. Fun troubleshooting when it isn’t “mission critical.”
Correct. Keyboard Maestro will not let you move/rename a file on to an existing file, including if the existing file is the same as the original file with different case.
Thanks for confirming, Peter.
I suppose one way to work around this would be to test for an "identical" name that also has case differences. If "true" paste the name from the source file with an added character appended to "force" the case change, then erase that added character after the paste. Or simply go with the AppleScript solution, using KM to trigger the script.
Tom
The AppleScript is the simplest way (provided that you know AppleScript).
Another alternative is to use the shell and an Execute a Shell Script action.
We're not pasting when using the KM move/rename action, we're essentially moving the file to a new name.
But you're correct in principle. When detecting a string that is equal except for case differences we write to a temp file with a different name and then rewrite to the desired name.
Here's a case-comparison example:
Download: String Case Comparison v1.00.kmmacros (9.9 KB)
You can move it to a unique name, and then move it to the destination name.
That will result in the failure having it renamed to a unique name though.
So you could do
The latter configured not to report or abort on error. That way if the second move fails, then the third move will revert the original change.
Hello Peter and Chris,
I approached it a little bit differently for now. Since the source file names have single digits for tracks 1-9 and the destination has a leading zero for tracks 01-09, the case of those names are handled exactly as they are in the source names, as the source names actually have different characters (no leading zeroes).
For all other tracks from Track 10 on, I have a KM macro that appends the letter "z" to the end of the destination file names, just before the "." for the extension. So, for instance, the destination file name of
10 All Quiet On The Western Front.wav would become
10 All Quiet On The Western Frontz.wav
Now, the name of the source cue is
10 All Quiet on the Western Front.wav
and that name with the proper case becomes the exact same name of the destination file, since the destination has a different character (z) than the source cue.
It’s a very quick process and handles the issue correctly, so I think that is the way I’ll go for now.
Tom
