I am just wondering is there a difference in what happens when I leave / at the end of a file path for example:

root /var/www/website.com/

And omitting it like:

root /var/www/website.com

How is this handled or is there a difference?

  • 1
    What's the context?
    – muru
    Jan 6, 2015 at 16:00
  • Well for this example I am specifying where the index.html file will be found on a nginx web server. Jan 6, 2015 at 16:02
  • @StephenFox: We're not wizards with crystal balls. Please amend the question with the information from your last comment and any other relevant information. Please also look at the documentation and tell us which parts do you not understand. Jan 6, 2015 at 16:41
  • 1
    Well it wasn't specific to any program it just so happened to be that it was nginx I was working with at the time that made me ponder the question. However from the answers, I can now see that the context matters, which answers my question. Now I can refer to the appropriate documentation as I can see that it is different regarding to the context. Jan 6, 2015 at 16:44

5 Answers 5


Trailing slash after a directory name matters in some programs and doesn't in others. For example:

  • In git / after filename means only directory and not a single file (from man 5 gitignore):

    If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find a match with a directory. In other words, foo/ will match a directory foo and paths underneath it, but will not match a regular file or a symbolic link foo (this is consistent with the way how pathspec works in general in git).

  • In ls (from wikipedia):

    When a directory listing of a symbolic link that points to a
    directory is requested, only the link itself will be displayed. In
    order to obtain a listing of the linked directory, the path must
    include a trailing directory separator character ('/', slash).

  • yet some other programs that I can't remember now (mostly Emacs macros I saw) that expect only a directory and not a regular file will accept both dir and dir/ and will add / when needed, for example to refer to a file inside dir.

I don't know how nginx works but see muru's answer.


In general, a path that does not have a trailing slash is ambiguous: it could be either a file or a directory. A path with trailing slash can only be a directory. Most shells give you the trailing slash automatically when using tab completion.

That does not mean you should always use a trailing slash; in fact some programs disallow its use. As the others stated, it depends on context. Each program interprets this differently.

One example where a trailing slash makes a huge difference, is rsync.

Given the directories source and target, the command rsync -a source target would copy everything to target/source. But with a trailing slash, rsync -a source/ target copies the contents of source into target directly, without creating a target/source subdirectory.

I'm often confused by this behaviour, so instead of relying on implicit subdirectory creation, I prefer to write it out. I sometimes even use a trailing /. to make sure no unwanted subdirs would be created since the subdir . is already there.


The context really matters. For nginx, while specifying the root for a location, it does not make any difference, since nginx knows it is a directory. However, it may make a difference elsewhere, since double-slashes can cause problems in URLs (that is, if you do something like blah/$request_uri while rewriting or proxying).

In general, it doesn't make a difference when it comes to *nix platforms. There are a few exceptions:

  • rsync behaves differently depending on whether the source directory path has a trailing slash or not. A good example of how rsync treats trailing slashes.
  • Adding a trailing slash can make an application aware that it is looking for a directory, instead of accidentally creating a file:

    cp blah non-existent-directory
    cp blah non-existent-directory2/
  • Similar to the above, in globbing, it can be used to force expansion to directories only:

    $ printf "%s\n" * | wc -l
    $ printf "%s\n" */ | wc -l

    Excuse the example. It's done on the root of a fairly standard Ubuntu installation, so no weird names were harmed during the execution of this example.

  • You can add to your exceptions that ls -l gives different results when used on a symlink to directory. Without trailing slash it shows information for the link itself, with trailing slash for the contents of the directory. Jan 6, 2015 at 16:48
  • 1
    @PavelŠimerda Arkadiusz's answer covers it - should add it again?
    – muru
    Jan 6, 2015 at 16:48
  • I overlooked it. It's up to you. Jan 6, 2015 at 16:49
  • 1
    @PavelŠimerda I think I won't - both answers pretty nicely cover the question without intersecting.
    – muru
    Jan 6, 2015 at 16:51

For URLs in browsers, http://www.example.com/ and http://www.example.com are the same URL. Whether or not the trailing slash is shown in the browser address bar is purely cosmetic - when the request is sent to the server the slash will be included. (http://www.example.com/foo and http://www.example.com/foo/ on the other hand are different URLs.)

The following is a very good explanation, taken from Stack Overflow: Trailing slash in URLs - which style is preferred?

In my personal opinion trailing slashes are misused.

Basically the URL format came from the same UNIX format of files and folders, later on, on DOS systems, and finally, adapted for the web.

A typical URL for this book on a Unix-like operating system would be a file path such as file:///home/username/RomeoAndJuliet.pdf, identifying the electronic book saved in a file on a local hard disk.

Source: Wikipedia: Uniform Resource Identifier

Another good source to read: Wikipedia: URI Scheme

According to RFC 1738, which defined URLs in 1994, when resources contain references to other resources, they can use relative links to define the location of the second resource as if to say, "in the same place as this one except with the following relative path". It went on to say that such relative URLs are dependent on the original URL containing a hierarchical structure against which the relative link is based, and that the ftp, http, and file URL schemes are examples of some that can be considered hierarchical, with the components of the hierarchy being separated by "/".

Source: Wikipedia Uniform Resource Locator (URL)


That is the question we hear often. Onward to the answers! Historically, it’s common for URLs with a trailing slash to indicate a directory, and those without a trailing slash to denote a file:

http://example.com/foo/ (with trailing slash, conventionally a directory)

http://example.com/foo (without trailing slash, conventionally a file)

Source: Google WebMaster Central Blog - To slash or not to slash


  1. A slash at the end of the URL makes the address look "pretty".

  2. A URL without a slash at the end and without an extension looks somewhat "weird".

  3. You will never name your CSS file (for example) http://www.sample.com/stylesheet/ would you?

BUT I'm being a proponent of web best practices regardless of the environment. It can be wonky and unclear, just as you said about the URL with no ext.


If you type in the shell:

    cd path/somedir

It moves your current directory to path/somedir.
But if you type:

    cd path/somedir/

It prints:

    bash: cd: path/somedir/: No such file or directory

Maybe because the / character means that the path is not complete, but continues, so if you put nothing after it is the same as referencing to a inexistent file.

  • 1
    Could not reproduce. Are you sure both paths exist?
    – muru
    Jan 6, 2015 at 16:26
  • 1
    Yes, whatever paths you used. Did you accidentally do: cd blah and then again cd blah/?
    – muru
    Jan 6, 2015 at 16:35
  • 1
    You do realize that for this to work both blah and blah/blah must exist, and that it's not a fault of trailing slashes? Did you try the reverse? cd blah/ then cd blah?
    – muru
    Jan 6, 2015 at 16:37
  • 1
    I believe that you omitted to return to the original "top" directory and tried to cd from ~/one/two instead. Then, of course you will get the error that you describe... because you did not create ~/one/two/one/two. I hope that clears things up... :-) Jan 6, 2015 at 20:03
  • 1
    @Greenonline yes it is! I've done this error due to my distraction.. I apologize to all of you!
    – Nenomaz
    Jan 9, 2015 at 22:57

Not the answer you're looking for? Browse other questions tagged .