People say you shouldn't use spaces in Unix file naming. Are there good reasons to not use capital letters in file names (i.e., File_Name.txt vs. file_name.txt)? Or is this just a matter of personal preference?

  • 1
    You can use caps but as a standard don't use it. Just use small letters and _ so file_name.txt is good.
    – Shabir A.
    Oct 28, 2015 at 19:14
  • 9
    There are some Unixy things that use filenames with capital letters... some examples include the Makefile, INSTALL, CHANGELOG and of course the venerable README.
    – Thomas
    Oct 29, 2015 at 4:19
  • PSR-2 - the de-facto naming standard of the PHP world, which runs by majority on Linux uses camelCase php-fig.org/psr/psr-2
    – jdog
    Oct 29, 2015 at 6:48

7 Answers 7


People say you shouldn't spaces in Unix file naming.

People say a lot of things. There are some tools that may screw up, but hopefully they are few in number at this point in time, since spaces are a virus proliferated by giant consumer proprietary OS corporations and now impossible to avoid.

Spaces make specifying filenames on the command line, etc., awkward. That's about it. The only categorically prohibited characters on *nix systems are NUL (don't worry, it's not on your keyboard, or anyone else's) and /, since that is the path separator.1 Other than that anything goes. Individual path elements (file names) are limited to 255 bytes (a possible complication if you are using extended character sets) and complete paths to 4 KiB.

Or is this just a matter of personal preference

I would say it is. Most DE's seem to create a slew of capitalized directories in your $HOME (Downloads, Desktop, Documents -- the D is very popular), so there's nothing bizarre about it. There are also very commonplace traditional files with capitals in them, such as .Xclients and .Xauthority.

A value of capitalizing things at the beginning is that when listed lexicographically they'll come before lower case things -- at least, with many tools, and subject to locale.

I'm a fan of camel case (aka. camelCase) and use it with filenames, e.g., /home/goldilocks/blueSuedeShoes -- never mind what's in there. Definitely a matter of personal preference but it has yet to cause me grief.

Java class files tend to contain capitals by nature, because Java class names do. And of course, let's not forget NetworkManager, even if some of us would prefer to.

1. There is a much more delimited, recommended by POSIX "Portable Filename Character Set" that doesn't include the space -- but it does include upper case! POSIX also specifies the more general restriction regarding "the slash character and the null byte" elsewhere in the same document. This reflects, or is reflected in, long standing conventional practices.

  • 7
    Mia: "Is that a fact?" Vincent: "No it's not, it's just what I heard." Mia: "Who told you this?" Vincent: "They." Mia: "They talk a lot don't they?" Vincent: "They certainly do."
    – corsiKa
    Oct 28, 2015 at 21:35
  • 5
    “The value of capitalizing something at the beginning is that when listed lexicographically […], they'll come before everything else.”—Of course, this only works if most of the filenames are lowercase, giving you a reason to reserve caps (at least leading caps) for your READMEs and Makefiles and so on. Oct 28, 2015 at 21:46
  • 4
    On many keyboards, ctrl-space or ctrl-@ or alt-0 will type a NUL.
    – dubiousjim
    Oct 28, 2015 at 21:53
  • 2
    @dodgethesteamroller I believe you are flat-out mistaken about forward slash (or more precisely, the byte with value 0x2F) in ext*. In fact, I don't believe it will even get to the filesystem; the VFS layer will disallow it regardless of the backing store.
    – zwol
    Oct 29, 2015 at 15:19
  • 4
    just don't use spaces in filenames and directory names. even if your system technically allows it, it will only cause your grief. Instead use "_" the underscore character.
    – SnakeDoc
    Oct 29, 2015 at 17:20

One reason to avoid caps in filenames is that sorting order in Unix is case sensitive, so files starting with a capital letter will appear out of order. That's the reason why Makefile is usually named using a capital M - it's one of the files you want to see first, without scrolling/skipping down trough a-l.

This said, you can do much worse in terms of file names:

  • using spaces will break some badly-written programs and scripts which don't quote file names properly
  • starting a file name with a - may cause problems as many programs will see it as a command-line option instead of a file name (e.g. rm -r will not remove a file named -r).
  • starting a file name with a . will hide it from many utilities and shell globbing (e.g. rm * will not remove files like .config)
  • using special characters like |<>*? and even non-printable characters like newline is technically possible, but may break scripts/programs similar to space character. The difference is that the space character is often used, so programmers tend to test their programs against it, while less popular characters often remain untested.
  • 4
    This tends no longer to be true, sorting in modern locales tends to be case-insensitive nowadays and many tools and shell globbings honour the locale for sorting file names. Oct 29, 2015 at 13:43
  • 2
    Did you mean to say: rm * will not remove files like .config?
    – Wildcard
    Oct 29, 2015 at 15:51
  • 1
    @Wildcard not really, but perhaps your example is more realistic than mine. My point was to show that filenames starting with a dot are immune to globbing even if the user specifies that dot explicitly. Oct 29, 2015 at 16:15
  • 1
    @DmitryGrigoryev, no they aren't. Try ls -ald .??* in any directory that has dot files.
    – Bill Barth
    Oct 29, 2015 at 18:52
  • 1
    I believe that it would be more appropriate to say "If you choose to use capital letters in file names, you should bear in mind the fact that sorting order in Unix is (sometimes) case sensitive."  The user may want this behavior, and Makefile and README are perfect examples of that.  Note also that this effect is negligible if the letter isn't the first letter in the name, so it's not a big deal if you use camelCase.  Sure, you might be surprised to see anOctagon before angle, but at least they'd be together in the listing. Oct 31, 2015 at 6:59

If you are going to interface with a Windows environment you should avoid capitals because Windows will lowercase everything. This is more often a problem going the other way; a link to Page_2.html will find page_2.html in Windows, but will fail in Unix.

  • 13
    That's not true. NTFS, VFAT, and exFAT are all case-insensitive but case-preserving, meaning they ignore case for purposes of lookup, but store case nonetheless. The same applies to HFS+, the default filesystem on OSX. NTFS even has a POSIX namespace which works exactly like all other Unices, i.e. very long filenames of un-interpreted octets, with only NUL and / prohibited. Oct 28, 2015 at 23:20
  • 5
    More to the point, "case-insensitive but case-preserving" is another way of saying "capable of silently overwriting file A because its name differs only in case from file B" (or vice versa, depending on which was saved later). In other words, if you're using a *nix shell to access an NTFS share, cat > Foo will overwrite file foo. This behavior is likely to be unexpected and confusing if you are used to case-preserving and case-sensitive filesystems such as ext*. Oct 29, 2015 at 1:52
  • 1
    @JörgWMittag Unless i'm mistaken, NTFS is not case-insensitive, it's just that windows works in mysterious ways.
    – Cthulhu
    Oct 29, 2015 at 11:10
  • 1
    @Cthulhu: AFAIK, NTFS has four different namespaces in which you can create names for files. (I don't know whether a single file can have a name in more than one namespace, though.) A "DOS" namespace (8.3, case-insensitive), a "long" namespace (case-insensitive, case-preserving, UTF-16), a special namespace for "short long" names, i.e. names whose case should be preserved but that fit into 8.3, and a POSIX namespace (a stream of octets other than \0 and /, case-sensitive). At least that's how I remember it. But I agree that it's kind-of a mess. There are further restrictions in the … Oct 29, 2015 at 11:34
  • 1
    … kernel, and even further restrictions in the API (actually, there are different APIs from different eras with different restrictions), there are restrictions due to compatibility with DOS and FAT, there are restrictions in the command interpreter, there are restrictions in the (graphical) shell, and there are restrictions in Explorer. And it's often impossible to reliably determine where a restriction is coming from. It's crazy. I once managed to create a file using the Explorer, which could not be opened, copied, moved, renamed or deleted using any tool I tried. It basically stayed on … Oct 29, 2015 at 11:37

One reason to avoid caps is that bashs tabcompletion is case-sensitive (at least by default)—this still trips me up every time I end up in front of a bash with default configuration. Sure, there are other popular shells, but this combined with the fact that bash is the default login shell on many OSes means that the default is oftentimes case-sensitive completion. Using all-lowercase filenames rather simplifies things here.

  • 2
    echo set completion-ignore-case On >> ~/.inputrc can help a bit, at least on your own system.
    – wchargin
    Oct 29, 2015 at 3:29
  • 2
    I’m not clear on what the point of this answer is — unless it is that you might forget how you “spelled” a filename.  For example, if you create a file named Foo and later type cat f(Tab), it will fail.  But the same thing happens if you type cat foo, cat Foobar or cat Fu — the fact that you will have trouble accessing a file whose name you don’t remember correctly doesn’t really have anything to do with autocomplete. Nov 2, 2015 at 21:14
  • @G-Man Touché. Still, using all-lowercase filenames means you have one less thing to remember about them. Nov 2, 2015 at 21:34

Since NL_Derek opened this can of worms, but didn't articulate it properly, I'll say this:

It's OK to use capital letters, but you should avoid creating files (in the same directory) that differ only by case, e.g., File_Name.txt and file_name.txt, because

  • If you somehow make the directory available to a Windows system, it will not be able to access both files.  It will probably be able to access only the one that appears first in the directory, regardless of which name you use.  (Except: it may give you access to them as FILENA~1.TXT and FILENA~2.TXT — type dir /x to see what short name (if any) goes with what long name.)
  • If the file system is actually a Windows file system (e.g., mounted from an exFAT or NTFS file system from an NFS server running Windows), the two names will (probably) not be allowed to coexist.  For example, if you do cmd1 > foo and cmd2 > Foo, you may end up with a single file, containing the output from cmd2.
  • Similarly, if you ever transfer the files to a Windows system, the two names will (probably) not be allowed to coexist.  For example, if you created an archive (e.g., zip) containing the two files, and extracted it on a Windows system, the second file would probably overwrite the first one.  Same thing if you transferred them to a Windows box with FTP or something similar.
  • Not only Windows, but several other OSes (VMS, I think, CP/M certainly, others...) Nov 2, 2015 at 20:08

Apart from technical reasons, I have a practical aspect to this. Sticking to lowercase letters will ensure that searches are easier unless one is too fond of using grep -i or locate -i. Sometimes, even camelCase can be confusing if one has to use a string of like-case words as in storageNYCDCPrimary. So, I find it best to stick to lowercase and pepper them with underscores or hyphens for readability, like storage_nyc_dc_primary.

  • snake_case is easy on the eyes - storageNycDcPrimary and StorageNycDcPrimary are both weird to read.
    – go2null
    Feb 6, 2019 at 22:08

I do consider it is best practice to avoid using capitals and spaces in filenames.

Some will say they do not agree but it is a matter or what I call religious beliefs: hard to discuss and agree on. Those not agreeing say that most of the tools are now fixed to be capitals and spaces friendly: they are right but this is not the question though.

The right question is how much do you need to use capitals and spaces in filenames. To this question, except when I am programming in Java, the answer is mostly all the time: I do not need capitals and spaces in my filenames. All spaces I replace by an underscore (_) or a minus sign (-), and because of that I do not use camel case (aka. camelCase) contrary to some of the other religion.

Many people called bullshit on me for doing and teaching that - some of them still do - some of them tripped on a tool that was not capital/space friendly and came to me saying that I was right and that they should have listened to me. Do whatever you want, and if you use capitals and spaces in filename, I hope you will never trip on a badly written tool. However, if you trip on such tool, hopefully again, it will not be hard to fix and will not cost your business and/or you lot of money and/or time. But if it ends-up having bad repercussions, you will remember that some told you in the past that using capitals and spaces in filenames is bad practice.

And one last thing, if you want to avoid all problems, no special characters in filenames (only lower case letters, digits, underscore and minuses [1]). This unwanted character list also includes all non ascii characters (yes, French and other non English people - and I am one of them - none of those: à, â, ä, ç, é, ..., ö, æ, œ, ...). This also extends to many other things, including login and password. I will let you guess what happen when you put a quote or double quote (' or ") in a login or password that is handled by a bash script not written by a confirmed sysadmin....

[1]: maybe we could extend that to ~, @, # and some others, but this is looking for trouble (and yes I know about emacs files...).

  • 1
    The last thing is something that should be handled by the authenticating system, not the user coming up with the password. If the system limits the set of allowed characters in passwords, it is a bad system. Nov 23, 2015 at 0:41
  • Well, limiting characters in password is a subject for debate: li1, oO0, ... depending on the fond, hard to communicate. Some would say that password should not be communicated, but a WiFi Key is a sort of password that I communicate to my friends when they are at my place...
    – jfg956
    Nov 23, 2015 at 7:41
  • That's a conscious choice on your part to avoid using some characters, rather than a limitation built into the system (in this example, the Wi-Fi standards, AP and client implementations, etc). If you're using a string of randomly-selected characters as a password, you can improve readability by using (or encouraging the recipients to use) a monospace font, or by simply using more distinctive glyphs if you're handwriting them (seriffed lowercase L, uppercase I, and digit 1; smaller lowercase O, rounder uppercase O, slashed or dotted digit 0; etc). Alternatively, you could use a passphrase. Nov 24, 2015 at 5:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.