Should a directory path variable end with a trailing slash?

Question

When defining a path to a directory as a variable or constant, should it end with a trailing slash? What is the convention?

pwd in Unix shows your curre

Answer 1

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).

Answer 2

I've never seen a firm convention either way.

Pretty sure, though, that whatever you settle upon, someone else will be 100% sure it should be the other way. So, the best idea is to tolerate things being set either way.

In the .NET world, Path.Combine() gives you a way to handle this - there are equivalents in other environments, from cmd files on up.

Answer 3

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

Answer 4

Maybe you should think about what your decision would mean for files. If you don't include the trailing slash at the end of a directory name you'll have to add it to the start of the file name.

Now, if for some reason, the path leading up to the file is missing when you concatenate strings, you end up with something like /filename which is not just a file but an absolute path from the root directory (wherever that may be in that context).

That's why I end my paths with a slash and keep files as files.

Answer 5

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.

Answer 6

Whenever I store directory paths or return them from APIs, I try and stick with the convention of keeping a trailing slash. This avoids the whole 'is it a file or a directory' ambiguity.

Addendum:
This is not intended to be a substitute for using methods that can tolerate either a trailing slash or its absence. Even using this convention I still always use Path.Combine(...) and similar methods.