Need help finding a special character to use for keywords in file names and paths

Looking for special character to use for keywords in file names and paths
Mac OS Tahoe 26.2
I find it very useful to use keywords starting with a special character in file names and paths. It makes searches faster and more effective.
For keywords, I use the “$” character as a prefix, for example $rent in all file and folder names pertaining to my rent.
I strongly dislike tags. Combining folders and aliases is too complicated and fickle such as when aliases break for whatever reason.
I put my keywords anywhere is the file or folder path or name: at the beginning, end, or anywhere within.
My system has always worked very well and I have been using it for years.
The reason I am posting is that I just discovered that using “$” creates problems with shell scripts via either terminal or run within Keyboard Maestro or BTT.
I want to change “$” for another special character which is “neutral” and will not cause any problems.
Apps / Scripts I use frequently and which may cause problems: Dropbox, Keyboard Maestro, Better Touch Tool, AppleScript , shell script, Java script (I copy the scripts from various forums and run them via Keyboard Maestro or Better Touch Tool)
Special characters that I would prefer because they are easy to type: one of the following +%&=?-!$£
I have excluded (right or wrong) the following because they cause problems with shell scripts & ! ? # { } < > ~ / |
Which special characters can I safely use ?
thanks very much in advance for your time and help

1 Like

For many years PopChar has lived in my menu bar. There are hundreds of candidates for your needs shown in it. You will want to pick one that not only has no interference with scripts etc, but also one that has a convenient keyboard shortcut. Omega, Ω (Option-z) for example.

4 Likes

thank you for your reply. How do I know that whatever character I choose will not interfere with my apps / scripts ?

Because my not computer savvy spouse accesses those files and folders, I have stick to something simple and straightforward, like one of he following +%&=?-!$£

It seems unlikely that one of the more obscure characters would be used in a scripting language, but I don’t know of any way of ruling it out. There are diphthongs for which there are keyboard shortcuts, for example œ, option-q.

1 Like

I would guess that any character in the Greek alphabet would have no special meaning to either the file system or scripting language.

2 Likes

@nello @drmoss_ca

Using the Omega symbol in Dropbox filenames can cause synchronization issues.

I would like to avoid guessing and use a simple to type character that can easily be used by a non computer savvy person (my spouse).

Sorry, didn’t see the list of software and file systems that you want to use with your tag-character:

  1. Dropbox
  2. Keyboard Maestro
  3. Better Touch Tool
  4. AppleScript
  5. shell script (which shell(s)?)
  6. JavaScript
  7. HFS+
  8. APFS

Have you looked up the character requirements for each of these to identify the characters that can NOT be used?

1 Like

That’s why I posted. It’s very tedious and I thought someone may already know.

You might try also asking this over at

2 Likes

I’m surprised that a filename beginning with a Greek letter is causing you Dropbox synchronization problems because Dropbox claims this filename (that begins with a Greek letter) is supported:

𝛑 formula.txt

1 Like

For decades I have used an underscore to begin filenames —primarily as a sorting trick—and I’ve never encountered a problem.

5 Likes

Consider the option and shift-option keys. They’re legal in file and folder names, and shouldn’t cause a problem in scripts.

For example, option-6 gives you the § character. Shift-option 7 is ‡, and shift-option v is ◊.

Ooh, how about :label:? It is a tag! Emojis are legal in filenames.

(Looks like Discord changed how it got displayed. It is the label/tag emoji, that looks like a shopping tag.)

And since emoji are not the same as the ASCII character that causes shell script problems, you could use :heavy_dollar_sign:.

1 Like

Underscores are definitely a deliberately “neutral” character in UNIX filenames, frequently recommended as a replacement for spaces. If you’re not using them as such in your filenames, it’s a good choice. If you’re working with a lot of files from other sources, though, you may find them included by others a lot. Dots and hyphens are also “neutral” in filenames, not requiring quotes or escaping.

The fundamental problem with the question being asked is that almost every non-alphanumeric character in the basic ASCII set (which is what you get without using the option key) may have a functional meaning in a shell script, depending on the commands being used. The only certain way to avoid that is by using an extended-ASCII character (one typed using the option key) instead.

3 Likes

This is true but since @Lucas043 uses it in front it will not work. A dot in front of a folder or file will make it invisible. Finder will not allow it, but terminal can do it. What I have used is a combination of a letter and underscore. x_Somefoldername, y_Somefoldername….

1 Like

In a Unix shell script, the only prohibited character is the directory separator (/).

Anything else can be used, as long as you observe proper quoting. Wrap strings in single- or double-quotes, or put a backslash (\) character before special characters so they won’t be processed by the shell.

I’m not going to go into a full discussion here, but you should get into the habit of always quoting strings in shell scripts that might correspond to file names. You should never assume that a file-name is safe to use otherwise - that’s almost certainly going to lead to bugs and/or security problems at some point. Especially on macOS and modern versions of Windows, where spaces in file names are common.

I assume that any other scripting language you’re likely to come across will have its own set of quoting rules for precisely the same reason.

And FWIW, the only prohibited character for Mac file names is the colon (:), which is used as a directory separator for the string-representation of paths in classic Mac OS.

The interesting thing is that Mac OS X (going back to 10.0, I think) has reconciled this by secretly swapping characters, depending on the API used. A file created with Mac APIs can have a / character (perfectly valid for MacOS paths) and that character will be replaced with a : character when accessed using Unix APIs. A file created with Unix APIs can have a : character (perfectly valid for Unix paths) and that character will be replaced with a / character when accessed using Mac APis. (I don’t know which is actually used on the storage device.)

6 Likes

Thank you very much @Shamino for an extremely interesting and helpful post. Exactly the type of insight I was looking for.

Your post steered me in the right direction and I did some more reading.

I have more than one hundred keywords starting with $ in file and folder names, and it would be a pain in the neck to have to rename them. In addition, I chose “$” because it stands out when looking at a list of files or folders

Reading the following “In zsh (the default shell in Tahoe) and bash, $ triggers parameter expansion” caused me to post my question to this forum.

If I understand correctly, a workaround would be to use single quotes (‘path/$bills’) or escape it ($bills). Double quotes (“$bills”) will not prevent expansion

If I want to stick to "$ ", may I ask you if my understanding is correct. Let’s take the path /Users/me/Documents/restaurant and hotel $bills

  • for use in a shell script, I would have to put the whole path in single quotes

  • I could use escape, but I would have to \ escape slash spaces and $bills which is tedious and error prone as in cd /Users/me/Documents/restaurant\ and\ hotel\ $bills

  • if I use double quotes instead of single quotes, I must still escape the $ inside double quotes to avoid triggering variable expansion.

  • if I use the path in a regex, I have to use the prefix \\ as in \\$bill. Otherwise $ would be interpreted as end of line.

thanks again very much !!!

1 Like

If you decide to replace the $, I believe the Finder can simplify the process. Select all the files in a folder and choose Rename… from the File menu or the Action button from the Toolbar. Tell the Finder to replace $ with your chose glyph(s). Files that do not have a $ in the name will be ignored. (I thought there used to be an option to replace text at the start, end, or anywhere in the filename, but I don’t see that option now. Can someone tell me where it is, if it exists?)

I don’t believe the Finder will make the replacement in subfolders, but it will remember the $ and replacement string.

This is on a MBA M3 running macOS 15.7.3, but I believe I used the same command on Macs running Big Sur.

1 Like

Name Mangler is excellent for changing filenames en mass:

2 Likes

thank you very much @nello

1 Like

Correct. Every shell is different, but this is common across all Bourne-like shells (sh, bash, zsh, and others). Although it’s really big, the manual page for bash is a great resource. Type man bash from a Terminal, or look here.

Here’s the page for the rules about quoting: Bash Reference Manual: Quoting.

Yes. Additionally, quoting may be necessary when the string is stored in variables.

For example, suppose you have three text files without spaces:

$ ls
File1.txt	File2.txt	File3.txt

You can use the following bash expression to expand a wildcard into an array of the names:

$ textfiles=(*.txt)

From there, you can query this array to get the count of files, and each individual name, as well as expand it into a string containing all the names:

$ echo ${#textfiles[@]}
3
$ echo ${textfiles[@]}
File1.txt File2.txt File3.txt
$ echo ${textfiles[0]}
File1.txt
$ echo ${textfiles[1]}
File2.txt
$ echo ${textfiles[2]}
File3.txt

So you could (for example) copy all the files to a destination with:

$ cp ${textfiles[@]} ~/target_dir

But what if there are spaces in the names? That all blows up:

$ ls
Another file.txt	First text file.txt	Yet another file.txt

$ textfiles=(*.txt)
$ echo ${#textfiles[@]}
3
$ echo ${textfiles[@]}
Another file.txt First text file.txt Yet another file.txt
$ echo ${textfiles[0]}
Another file.txt
$ echo ${textfiles[1]}
First text file.txt
$ echo ${textfiles[2]}
Yet another file.txt

If you would try to use that cp expression, it will fail, because all those spaces will parse the sub-strings as if they were separate file names:

$ cp ${textfiles[@]} ~/target_dir/
cp: Another: No such file or directory
cp: file.txt: No such file or directory
cp: First: No such file or directory
cp: text: No such file or directory
cp: file.txt: No such file or directory
cp: Yet: No such file or directory
cp: another: No such file or directory
cp: file.txt: No such file or directory

But bash’s variable-expansion rules will do the right thing if you quote the expression:

(The set -x command tells the shell to print out what it is about to execute, so you can see the internal quoting):

$ set -x
$ cp "${textfiles[@]}" ~/target_dir/
+ cp 'Another file.txt' 'First text file.txt' 'Yet another file.txt' /Users/dcharlap/target_dir/

$ ls -l ~/target_dir/
total 0
-rw-r--r--  1 user  staff  0 Feb 16 12:39 Another file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:39 First text file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:39 Yet another file.txt

Note that the shell provides all the necessary quoting and cp does the right thing this way.

This will work if you have dollar signs or any other special characters in the file names:

$ ls -l
total 0
-rw-r--r--  1 user  staff  0 Feb 16 12:42 $First text file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:42 $Second text file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:42 $Still more text files.txt

$ textfiles=(*.txt)
$ echo "${textfiles[@]}"
$First text file.txt $Second text file.txt $Still more text files.txt

$ cp "${textfiles[@]}" ~/target_dir/
$ ls -l ~/target_dir/
total 0
-rw-r--r--  1 user  staff  0 Feb 16 12:43 $First text file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:43 $Second text file.txt
-rw-r--r--  1 user  staff  0 Feb 16 12:43 $Still more text files.txt
3 Likes