I have close to 7,000 macros and made the mistake of using all possible Dropbox and Mac OS forbidden characters in macro names for the purpose of classification and facilitating searches. It was a terrible idea and has all kinds of unforeseen complications such as not being able to save to a Dropbox folder.
I want to backup, save etc to dropbox including any complex macro I may be working on, without having to deal with constant Dropbox alerts. Zip is a workaround. These forbidden characters are not necessary. Just end up being a pain in the neck
Would you know if there is any way to create a forbidden character smart group?
MacOS doesn't have any character restrictions in filenames, except ":" (which I think is used as a folder separator) and null (\0). I think filenames can contain any other character, including CR, LF, Tab, and Unicode characters like emojis.
So you can have a file with this name:
🔥🔥🔥.jpg
Why do you want characters to be rejected?
There are probably some macOS apps that don't let you use certain characters, but that's an app restriction, not a macOS restriction.
You can use / in file and folder names in the Finder, but in general, I'd avoid that character as it is converted to : in the file system. Fire up the Terminal app and you'll see.
All other characters you listed are perfectly fine, but as you have discovered several cause issues with Dropbox.
Note that the Keyboard Maestro export commands convert : and / characters to a - in macro group and macronames when the folders and files are created.
what do you call "null" ? test \0 testing.pdf seems to work fine.
multiple "." does not seem to be a problem. Mac OS only considers everything after the last "." as the file extension
I am creating a shortlist
if filename starts with "." the file becomes invisible ie only visible is file browser set to show invisibles
":" is automatically converted to / by Mac OS
total path length cannot exceed 255 characters
Keyboard Maestro export commands convert : and / characters to a - in macro group and macronames when the folders and files are created. (quoting @_jims)
So my major issue is with dropbox restrictions
When I created a smart group using your filter, I noticed that those characters were used in many subroutines used by macros in the KBM library). Is it perhaps safer to avoid dropbox = 1 if I want to make sure that the macros using those subroutines are working ? This is a general question. I don't want to get into the many macros which use subroutines. thank you
The macro's name is unimportant -- it's the exported/saved file's name that matters. So what you could do is "cleanse on save", allowing you to keep using useful names in the Editor while being able to save to Dropbox and similar. That can result in a disconnect between the macro/Group name and the file/folder name, of course.
Ignore that -- you may be using Dropbox now, but what about next week? Next year?
For true portability, limit yourself to a-zA-Z0-9, _, - and ., and never start nor end the name with .. Anything outside that character set could cause trouble somehow, somewhere, so you may as well avoid it now. It also makes things easier programmatically -- replace all spaces with _ and anything that's not in that character set with -, test for uniqueness and, if necessary, start incrementing the name (eg name-1.text, name-2.txt) until unique.
That's what Zip Smart Group(s) does when local_DropboxSafe = 1. Both the name of the macro groups and the macros are cleansed (a.k.a. sanitized).
IMO, to be this conservative, would be overkill particularly with trends moving in support of unicode. But if I was arguing this conservative position, I'd even avoid -.
macOS, Keyboard Maestro export commands, and Zip Smart Group(s) increment as follows to avoid collisions:
abc.txt
abc 2.txt
abc 3.txt
@ronald, if you so inclined to cleanse your macros and macro groups within the Keyboard Maestro editor, there are shell script functions within Zip Smart Group(s) that could be used in combination with macro renaming steps. Note again, I'm not suggesting you do that, but if you are really motivated to do so, that shell logic could be a start.
I've migrated a couple of PB between systems in the last few months, and have had all sorts of "fun" with Mac users' filenames that were valid on the source (chiefly because of how the Mac smbd handles Mac-ish names on remote volumes) but not on the destinations. So my conservatism is born from a desire not to put anyone else through similar
But I've never seen a problem with -. Do you have any examples?
In fact, you could argue that the list of "valid" names should be further restricted -- there's a bunch of reserved Windows names (CON, NUL, COM1, COM2, etc), for example.
How far people should go will really depend on what they expect to do with the files in the foreseeable future and where they fall between the the utility of "expanded" names on one side and the possible inconvenience of dealing with them on the other.
very good points. I dropped the idea. I discovered that the forbidden characters in my initial post were in fact forbidden for reasons of inter operating system compatibility, not Mac OS . thank you
I hear ya, @Nige_S. I've got several scars myself! But with that said, I'd never even think to restrict my Keyboard Maestro names to a-zA-Z0-9 , _ , - and .
Not necessary related to macOS, but I vaguely remember meeting this restriction on a proprietary process control system. This was years ago, and even then I was aghast.
Yes, I thought of that too, but thankfully I haven't worked on Windows since 2017.
Neither would I! But what I do and what I'd advise others to do as "best practice" are rarely the same... I do something that blows up in my face -- my bad. I tell others to do something that has that result -- that'll come back to haunt me later
)
