Use of file names ending with a period

filenames

Why does Unix allow files with a period at the end of the name? Is there any use for this?

For example:

filename.

I am asking because I have a simple function that echoes the extension of a file.

ext() {
  echo ${1##*.}
}

But knowing it will print nothing if the filename ends in a ., I wondered whether it would be more reliable to write:

ext() {
  extension=${1##*.}
  if [ -z "$extension" ]; then
    echo "$1"
  else
    echo "$extension"
  fi
}

Clearly this depends on what you are trying to accomplish, but if a . at the end of the file name were not allowed, I wouldn't have wondered anything in the first place.

Best Answer

Unix filenames are just sequences of bytes, and can contain any byte except / and NUL in any position. There is no built-in concept of an "extension" as there is in Windows and its filesystems, and so no reason not to allow filenames to end (or start) with any character that can appear in them generally — a . is no more special than an x.

Why does Unix allow files with a period at the end of the name? "A sequence of bytes" is a simple and non-exclusionary definition of a name when there's no motivating reason to count something out, which there wasn't. Making and applying a rule to exclude something specifically is more work.

Is there a use for it? If you want to make a file with that name, sure. Is there a use for a filename ending with x? I can't say I would generally make a filename with a . at the end, but both . and x are explicitly part of the portable filename character set that is required to be universally supported, and neither is special in any way, so if I had a use for it (maybe for a mechanically-generated encoding) then I could, and I could rely on it working.

As well, the special filenames . (dot) and .. (dot-dot), which refer to the current and parent directories, are mandated by POSIX, and both end with a .. Any code dealing with filenames in general needs to address those anyway.

Related Question