title: Proper way to set PHP include path for *Nix and Windows
body: <p>Is this the proper way to <code>define</code> an include path for <strong>both *nix and Windows</strong>?</p>
  
  <pre><code>define( 'INCPATH', realpath( dirname( __FILE__ ) ) . '/' );
  </code></pre>
  
  <p>Note the trailing forward-slash I included above. Is the forward-slash for includes/requires the same for both OS's, as well?</p>
  
  <p><strong>EDIT (UPDATED WITH ANSWER):</strong></p>
  
  <p>From what I can gather, my code below is the proper way to universally define an include/require path for both *nix and Windows OS's. Feel free to correct anything in the comments below.</p>
  
  <p>The thing that confused me were the many examples I saw showing replacement of <code>back-slashes (\)</code> into <code>forward-slashes(/)</code>. Based on some of the answers below, this is unnecessary.</p>
  
  <p>So the final correct code (for the purist) is:</p>
  
  <pre><code>define( 'INCPATH', realpath( dirname( __FILE__ ) ) . DIRECTORY_SEPARATOR );
  </code></pre>
  
  <p>That code produces the following results:</p>
  
  <p><code>*nix: /path/to/the/file/</code></p>
  
  <p><code>Windows: C:\Path To\the\file\</code></p>
  
  <p>A brief explanation, working our way from the inside (<code>__FILE__</code>) out (<code>realpath()</code>):</p>
  
  <p><a href="http://www.php.net/manual/en/language.constants.predefined.php" rel="nofollow noreferrer"><strong>FILE</strong></a> The full path and filename of the file. Always contains an absolute path with symlinks resolved.</p>
  
  <p><a href="http://www.php.net/manual/en/function.dirname.php" rel="nofollow noreferrer">dirname()</a> The returned string is <em>path</em> with any trailing /component removed. Responsible for removing the filename.</p>
  
  <p><a href="http://www.php.net/manual/en/function.realpath.php" rel="nofollow noreferrer">realpath()</a> Returns the canonicalized (normalized/standardized) absolute pathname on success. The resulting path will have no symbolic link, <code>'/./'</code> or <code>'/../'</code> components. I assume this is included for thoroughness because <code>__FILE__</code> already resolves symlinks. Or maybe it's included to resolve relative paths? Either way, it seems to solidify our goal.</p>