in reply to Re: Resolving correct directory path in a symlinked directory
in thread Resolving correct directory path in a symlinked directory

Unfortunately getcwd() returns the same result as cwd.

However, your other comments prompted me to look at $ENV{PWD} - and that variable actually contains the correct path (as I was hoping to find it). So that solves my problem. Thanks.

  • Comment on Re^2: Resolving correct directory path in a symlinked directory

Replies are listed 'Best First'.
Re^3: Resolving correct directory path in a symlinked directory
by beermad (Novice) on Apr 30, 2011 at 19:24 UTC

    ...and as a bonus, Apache exports a very useful environment variable for the purposes of this: SCRIPT_FILENAME.

Re^3: Resolving correct directory path in a symlinked directory
by afoken (Chancellor) on May 01, 2011 at 07:34 UTC

    $ENV{'PWD'} is set by the shell (or by the Cwd module when importing the modified chdir function from it) -- but there is no shell when CGI programs are invoked (except when the CGI program is a shell script). And to make things worse, the CGI specification (no longer available at the original site) has no common specification for the current working directory (cwd). Even the CGI RFC 3875, written much later, has only a very restricted specification:

    AmigaDOS
    The current working directory for the script is set to the directory containing the script.
    UNIX compatible operating systems
    The current working directory for the script SHOULD be set to the directory containing the script.
    POSIX compatible operating systems using the EBCDIC character set
    The current working directory for the script SHOULD be set to the directory containing the script.

    So, the cwd problem is only solved for AmigaDOS, which is really common among web hosters today. ;-) If you consider your OS "UNIX compatible" or "POSIX compatible using the EBCDIC character set", you SHOULD set the cwd to the directory containing the script, but you DON'T HAVE TO do so. You can freely set the cwd to any other directory you like, e.g. / or /var/empty, without violating the RFC or the original specification. For every other operating system, you are free to set the cwd to whatever directory you like, if the operating system has the concept of a cwd.

    Next problem: Even if your operating system looks roughly like UNIX, is it really UNIX? Probably NOT. Wikipedia lists: Systems licensed to use the UNIX trademark include AIX, HP-UX, IRIX, Solaris, Tru64 (formerly "Digital UNIX"), A/UX, Mac OS X, and a part of z/OS. No Linux. No BSD.

    So, your operating system looks like UNIX, but it is not "UNIX" in that sense. Perhaps it is POSIX compatible? Well, the RFC does not specify the cwd except if your operating system also uses the EBCDIC charset, and even then, the wording is "SHOULD", not "MUST". Neither Linux nor *BSD uses EBCDIC, perhaps except on machines rarely used for web hosting.

    Windows? POSIX compatible? It doesn't even implement fork() and exec() -- but you can add some compatibility layers. But even then, Windows won't use EBCDIC.

    So, the cwd is undefined except for AmigaDOS. Unless you know what web server you use, how it implements the CGI, and what parts of the implementation are guaranteed (i.e. documented).

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)