What technical reasons exist for not using space characters in file names

file managementfilenamesoperating systems

Somebody I know expressed irritation today regarding those of us who tend not to use spaces in our filenames, e.g. NamingThingsLikeThis.txt — despite most modern operating systems supporting spaces in filenames.

Are there technical reasons that it's still common to see file names without (appropriate) spaces? If so, what are these technical reasons that spaces in filenames are avoided or discouraged, and in what circumstances are they relevant?

The most obvious reason I could think of, and why I typically avoid it, are the extra quotes required on the command line when dealing with such files. Are there any other significant technical reasons?

Best Answer

Whitespace characters in filenames can be a right royal pain in the proverbial in many contexts on the command line, and in scripts, where you have to be careful to make sure they are properly escaped so don't look like separators to the commands you are running.

It is just safer not to have them there, even if you are sure the file/dir/what-ever is never going to be used in such a context.

That, and old habits die hard.

Related Solutions

Linux – Using underscore in file names

As far as the operating system is concerned they both are as usable as each other.

One thing I would note - some software (such as some video playing systems - XBMC etc) will automatically replace underscores with spaces when displaying files to make them look nicer.

For that reason alone I'd be tempted to stick to underscores.

Also, hyphens are used for switches to commands, so it may be a little confusing having hyphens in you filenames as well as in your command switches.

Other than that it's purely down to personal choice.

What characters are safe in cross-platform file names for Linux, Windows and OS-X

Summary:

Windows: anything except ASCII's control characters and \/:*?"<>|
Linux, OS-X: anything except null or /

On all platforms it is best to avoid non-printable characters such as the ASCII control-characters.

Windows

In Windows, Windows Explorer does not allow control-characters or \/:*?"<>| You can use spaces. If you use spaces, you will often have to quote the filename when used from the command line (but GUI apps are unaffected so far as I know). Windows filesystem such as NTFS apparently store the encoding with the filename, but UTF-16 is standard.

Some parts of Windows are case-sensitive, other parts are case-insensitive. It is easy to create distinct filenames like "Ab" and "ab" on a Windows NTFS filesystem. These names refer to separate files which contain distinct separate content. However, although the Windows command-prompt will happily list both files using dir, you cannot easily access or manipulate one of them using commands such as type. See below.

Linux, OS-X

In Linux and OS-X only / of the printable ASCII set is prohibited I believe. Some characters (shell metacharacters like *?!) will cause problems in command lines and will require the filename to be appropriately quoted or escaped.

Linux filesystems such as ext2, ext3 are character-set agnostic (I think they just treat it more or less as a byte stream - only nulls and / are prohibited). This means you can store filenames in UTF-8 encoding. I believe it is up to the shell or other application to know what encoding to use to properly convert the filename for display or processing.

Conclusion

So you could probably safely use something like ✣ (if it weren't so hard to type)

Case-(in)sensitivity in Windows

C> dir /B
Ab
aB
аB

C> type Ab
b
b

C> type aB
b
b

C> type аB
unicode homograph

Note that we cannot type the contents of the second file, the Windows type command just returns the contents of Ab instead. The third file would be distinct from aB on Linux also.

(Windows 10 NTFS).

Best Answer

Related Solutions

Linux – Using underscore in file names

What characters are safe in cross-platform file names for Linux, Windows and OS-X

Related Question