Are bash commands on OSX case insensitive? I type "which TR" and it shows /usr/bin/TR, though there is no such binary there. Same thing for other binaries, when capitalized. Or is Terminal.app maybe doing this translation? How do I turn this off?
-
6The reason I wanted to turn it off is silly, really. I'm used to case sensitivity when working at the shell. I am just worried this feature will trip me up. Example, I write a bash script, mistype 'lS'; the script will run fine on OSX. I move it to my cenTOS box, and it breaks. Granted, this would be easy to detect and fix, but could avoid the scenario entirely if I could keep the scripts working the same way between the two systems. I discovered this by accident, and it hasn't been a nuisance thus far, so I probably will not go through the exercise changing filesystems just for this.– verbozeCommented Aug 19, 2011 at 1:30
-
6The reason you would want to turn this off is that case insensitivity causes problems for some apps, like SVN. Case insensitive globbing could be useful, but SVN gets very very confused if you create a file called "Foo", then somehow the repository creates a reference to "foo".– user41214Commented Feb 5, 2013 at 19:01
-
3Another reason to disable: I have had a script ~/bin/CC in my path since circa 1980. cc plus some pleasant defaults. It has worked from UNIX v6 through v7, Eunice, BSD 4.1, 4.2, 4.3, SVr4, Xenix, Gould UTX, Linux, cygwin... and it failed for the first time on MacOS, infinite recursion.– Krazy GlewCommented Oct 9, 2015 at 2:24
-
1This just screwed me over as well. A build and dev deployment that work fine on OSX break in test on Ubuntu because I mistyped one letter in my gulp script in lower case rather than upper-case. I'm not a fan of this feature because it forgives errors that, in all likelihood, your production system won't.– Bart ReadCommented Jun 22, 2016 at 14:31
-
1This did trip me up because something that worked in the macOS terminal did not work for me when working on CentOS and I was staring at the code until I realized that the possibility existed for case insensitivity on Mac.– demongolemCommented Sep 2, 2020 at 20:29
5 Answers
This is actually a feature of the filesystem of your disk, not bash or Terminal.app.
HFS+ (the Mac filesystem) is usually configured to be case insensitive but case preserving. This means that the file system will consider foo
and FoO
to be the same, but when you create a new file it will remember which letters where capitalized and which were not.
When you format a disk with HFS+ you can chose whether the file system should case sensitive or not. If you chose to format with UFS (Unix FileSystem) it is always case sensitive, AFAIK.
To check whether a disk is case sensitive, run:
diskutil info <device>
For example:
diskutil info disk0s2
Look for the Name:
line. If it reads something like Mac OS Extended (Case-sensitive, Journaled)
it means that it is case-sensitive. If it just reads Mac OS Extended
(without the Case-sensitive
) then it is only case preserving but not case sensitive.
Since macOS 10.13, the default Apple file system is now APFS which is case-insensitive but case-preserving by default. Like HFS+, it can also be formatted to be case-sensitive. To see which mode is used you now have to use:
diskutil ap list
(diskutil info <device>
does not print whether an APFS slice is case-sensitive or not.)
-
7Outside of Unix, the case preserving nature isn't so unusual. For example, NTFS is the similar: not case sensitive by default, but you can format it so it is. I also think that the case insensitive is default came via Mac OS 9, but the fact that a lot of Mac and Windows developers are lazy in this respect and don't care about correct casing makes it almost impossible to switch to case sensitive as default, it breaks lots of apps. Coming from Unix, I found it very strange at first as well.– DarkDustCommented Aug 17, 2011 at 16:57
-
1I have to admit I never used Classic Mac OS, so was guessing. Either way, this is the answer, and DarkDust put it better than me so this one should be accepted I think.– stuffeCommented Aug 17, 2011 at 17:11
-
7Every version of Mac OS has been case-insensitive-but-preserving, for usability reasons. While UNIX favours precision (byte-by-byte comparisons of filenames), it can be a usability nightmare for end users who accidentally save 'Resume' and 'REsume' and then get confused when they open the wrong version and all their changes are gone.– Dan UdeyCommented Aug 17, 2011 at 17:30
-
2On the other hand, it can also be a "usability nightmare" when typing "HEAD" at the command-line results in the program /usr/bin/head (show first lines of a file) being executed instead of /usr/local/bin/HEAD (from LWP: make an HTTP 'HEAD' request).– TMLCommented Apr 23, 2013 at 17:12
-
5Thinking that for every uppercase character there is one lowercase equivalent and vice versa is typical of English speaking programmers, and is not locale-independent. I don't know what solution has been adopted for Turkish, where there is the dotted lowercase
i
corresponding to the DOTTED uppercaseİ
, while the dotless uppercaseI
corresponds to the DOTLESS lowercaseı
, but ANY solution will be bad. And what about the Germanß
, often capitalized with 2S
s? And accents that are often left out when capitalizing? And... Case sensitivity does away with all of these headaches. Commented Jun 19, 2015 at 16:42
I managed to fix this with one line by following http://blog.nickburwell.com/blog/2008/11/mac-os-x-terminal-case-insensitive-auto
echo "set completion-ignore-case On" >> ~/.inputrc
-
This appears to be the only answer that answers the "how can I turn this off" portion of the OP. Commented Dec 15, 2019 at 0:39
-
Take a look at your filesystem, as there are both case sensitive and case insensitive variations on HFS. The default is case insensitive, in which case it's not so much a case of BASH, but the underlying filesystem. You can test this by formatting a spare USB stick with the case sensitive option, and copying files over ato repeat your test, etc.
It's your file system thing.
I'm using APFS, it's also case insensitive but case-preserving. This post provides a good explanation about H(ierarchical)FS and APFS.
#include <sys/stat.h>
#include <iostream>
int main(int argc, char **argv) {
struct stat sb;
int ret = stat(argv[0], &sb);
std::cout << ret << std::endl;
}
output of this program using stat
:
$ ./a.out ./test_dir/cat.png
0
$ ./a.out ./test_dir/caT.png
0
a simple bash test
$ cp cat.png caT.png
cp: caT.png and cat.png are identical (not copied).
As for bash, I believe it's also case insensitive on Mac OS if you are using the default HFS or APFS since command executable is also a file and when you type a command name, the name is used search through search PATH to find that file to be executed.
$ echo x X
x X
$ eChO x X
x X
Bash is definitely case sensitive.
I just typed whoami
into terminal and the caps lock button was on.
I got a completely different response from WHOAMI
.
I can see there is a WHOAMI
command with which
but I can't find it with ls
.
-
9This isn't the shell being case sensitive, it's the
whoami
program itself. It's actually the same program asid
, but it checks which name it was run as, and uses a different output (equivalent toid -un
) if run under the name "whoami". That check is case sensitive. Compare the output ofid
,WHOAMI
,WhOaMi
,WhoAmI
, etc. Also, compare the output ofls -li /usr/bin/whoami
vsls -li /usr/bin/WHOAMI
, and note that the inode number (the first thing listed in the output) is the same -- they're two different ways of specifying the exact same file. Commented Apr 21, 2017 at 16:57