Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Which characters are allowed and which of them must be escaped on the command line in different operating systems?

share|improve this question
There are some useful answers below, but what are you trying to achieve? Coding up your own character white-listing routines is probably not the best route. – medina Jun 12 '10 at 23:16
Thanks to everyone! All answers are helpful. What I need the info for is: I'm writing a tool which would tag files across the filesystem, by altering their names (no metadata). – Jun 13 '10 at 12:48
See also answer on superuser. – pevik Jun 21 at 10:21
up vote 17 down vote accepted

There's a discussion of filename characters in the Wikipedia article on File Names.

You may find this essay informative: Fixing Unix/Linux/POSIX Filenames.

This article compares OS X and Windows XP: X vs. XP: Forbidden Characters in Filenames (PDF, see pp approx. 64-66).

Things That Shouldn’t Be in File Names for $1,000 Alex

I don't know which characters must be un-escaped, but in Linux, it's probably not a good idea to escape the characters that may have special meaning such as "n" (newline), "t" (tab) and others, but that's generally not a problem in file operations. Perhaps you mean "escaped" rather than "unescaped". The most common ones are ones that the shell will interpret such as space, ">", "<", etc. See some of the articles I linked for a discussion of those.

share|improve this answer
This isn't really an answer - all the information is external. And some of those links are broken now. – Steve Bennett Jan 11 at 22:49

The only characters not allowed in a filename in *nix are NUL and /. In Windows, only NUL, :, and \ are truly not allowed, but many apps restrict that further, also preventing ?, *, +, and %.

At no point do any characters in a filename need to be escaped except as required in order to not be interpreted by the shell.

share|improve this answer
The second point deserves emphasis. Usually, “escaping” refers to a shell mechanism that allows the user to specify strings (e.g. pathnames) that contain characters which the shell would otherwise treat in a special manner. If the OP means using something like “percent encoding” to encode otherwise disallowed characters, then that is a purely application level “pathname protocol” that each involved program must adopt (or not). – Chris Johnsen Jun 13 '10 at 4:20

If you create a file on Windows with Explorer using one of the following characters, it will complain that the characters are not allowed:

\ / : * ? " < > |

A good reference is here:

Naming Files, Paths, and Namespaces

Microsoft further states:

"... on Windows-based desktop platforms, invalid path characters might include ASCII/Unicode characters 1 through 31, as well as quote ("), less than (<), greater than (>), pipe (|), backspace (\b), null (\0) and tab (\t)."

share|improve this answer
I remember reading a couple years ago that user-mode Windows has those restrictions as well as being case-insensitive ("ABC.txt" === "abc.txt"). However, kernel-mode Windows has fewer restrictions and is case-sensitive ("ABC.txt" !== "abc.txt" just like *NIX). For all intents and purposes, though, the above characters will apply to the majority of programs because they run in user-mode. – CubicleSoft Mar 3 '13 at 13:36

On Linux and other POSIX compatible systems, "/" is reserved as it's the directory separator, and "\0" (the NULL character) designates the end of the string. Everything else is allowed.

share|improve this answer
Although it's highly recommend to avoid newlines, tabs, control characters, and the like, and to make sure the filename is valid UTF-8. – Flimm Sep 23 '15 at 10:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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