Should a directory path variable end with a trailing slash?

I go with the trailing slash because:

  1. "If it ends with a slash, it's a directory. If not, it's a file." is an easy convention to remember.

  2. At least on the operating systems I commonly use, doubling the slash causes no problems, while omitting the slash causes big ones. It is, therefore, safest to both put the slash into the variable and use "$path/$file" when making use of it.


I don't include the trailing slash when I, for example, define a directory for storing files. That is because I will use it like

$store_file = "$store_path/$file_id";

I will always add a trailing slash before using a variable that's supposed to hold a directory path. I think it's better to always add one than to wonder if the trailing slash is included.


I know that this is 10 years old, but I wanted to throw in my very opinionated $0.02.

No. No. Absolutely no.

We are talking about a Unix system. In reference to the directory itself, it is a node like any other. When referring to the directory, it should not ever have an unescaped slash in its name (ref: dirname, pwd, ~, echo $HOME, echo $PATH, the output from ls, et al).

When referring to a directory's contents, then you need a slash. That is to say, ls /home/karl/ is more appropriate than ls /home/karl (FTR, I almost always do the latter because ...well, lazy).

When utilizing a variable containing a directory to create the full path to a file, you would always expect to include the slash (i.,e: cp ${HOME}/test ${OTHER_DIR}/).

It is expected that a directory not end in a slash. Any expectation that a directory ends in a slash is wrong. Thus adding a slash to the end of a *_DIR variable's value would be subverting expectations.

As for tab completion, the expectation here is that you are going into that directory. Thus, the assistance provided by tab completion is to get you into that directory so that you can make the next choice based on its contents.

(reference from comments: Filepath Misconceptions, from Wikipedia's Talk:Path_(computing) page. Thanks, john c. j.)

It is worth noting that just because it is wrong doesn't mean that tools/packages/libraries never do it. It is a far-too-common occurrence that such things add a trailing slash when none should exist. Therefore, as Bevan and Paul F both suggested, when using 3rd party tools, it is best to remove any trailing slashes that might exist in directory names.

Unix Inodes

The inode (index node) is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory.

-- https://en.wikipedia.org/wiki/Inode

Filesystem Hierarchy Standard

The standard for the Unix filesystem (the Filesystem Hierarchy Standard, AKA FHS) clearly show that directories are not thought of as having a trailing slash, but rather directory contents begins with a slash (the only exception to this is / because we will not refer to the filesystem root by using an empty string ...and one should never be creating files there anyway.)

-- http://www.pathname.com/fhs/pub/fhs-2.3.html

-- https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard


Yes, it should, as:

Pathname + filename = fully qualified file location.

SO the slash between the last directory and the filename needs to be either at the end of the pathname or the start of the filename. Prefixing filenames with a / means you need to take this into account if you just want to open a file (i.e if you assume that an unqualified filename is in the current working directory).