The most portable solution would be to avoid the use of relative paths (and pwd/cwd) altogether. If you really, truly need to go forward with a particular path, you can avoid the "auto-resolving link" problem altogether by constructing the fully qualified path and using that in your program.

In general, littering your code with relative paths and dependencies on the current working directory is not a good idea. There are several problems that can result:

• The current working directory might not be what you think it is, not just because the real path is substituted for the symbolic path, but also because cd can fail if you try to switch to a directory for which your effective user (EUID) doesn't have permission.
• In some cases, particularly with mounted drives, you can get stuck in no-mans land. If you are going to use cwd, you should avoid fastcwd for that reason: see http://rt.cpan.org/Public/Bug/Display.html?id=13851 (ignore the fact that this is a bug report - the discussion about it is the interesting part as regards portability issues)
• Your code is unlikely to work in taint mode which does not like relative paths.
• And in general, your code will not be portable to any web interface because the "current" directory in that context is essentially undefined - it could be anything on the face of the planet (well, web server).

See File::Spec for a portable way to attach relative paths to a fully qualified starting path.

About the only situation where I can see a genuine use for cwd is (a) start-up situations (b) incoming information (but here lie security risks which is why taint mode doesn't let you use them) and (c) an occasional piece of software that actually requires itself to be run with a particular directory or kind of directory as "current". Most applications do accept fully qualified paths even if the documentation examples only illustrate relative path parameters for convenience

In start-up/incoming information situations you may want to find certain files based on the starting directory of a user. However, in my own code, I immediately convert that to a fully qualified path and from there on in use fully qualified paths in the code.

Cwd's getcwd simply returns what the system provides. Your shell is actually tracking the work directory separately from the system, but it provides it via $ENV{PWD}. You can use it safely as follows:

use Cwd qw( getcwd );

sub my_getcwd {
use Cwd qw( );

sub getcwd {
   my $cwd = Cwd::getcwd();
   if (exists($ENV{PWD}) && $ENV{PWD} ne $cwd) {
      my $e = my ($e_dev, $e_node) = stat($ENV{PWD});
      my $c = my ($c_dev, $c_node) = stat($cwd);
      if ($e && $c && $e_dev == $c_dev && $e_node == $c_node) {
         $cwd = $ENV{PWD};
      }
   }

   return $cwd;
}

print Cwd::getcwd(), "\n";
print getcwd(), "\n";
[download]

/tmp/ikegami
/home/ikegami/tmp
[download]

$ENV{PWD} has the same portability problems as `pwd` does though, and the OP was specifically looking for a portable solution to the problem.

Getting bash's pwd isn't possible where bash isn't used. What's your point? Are you implying that the code I posted isn't portable? If so, you'd be mistaken.

Update:

Every tool that gives you bash's pwd use $ENV{PWD}.

$ /bin/pwd              GNU pwd
/tmp/ikegami

$ bash -c pwd           bash's builtin
/home/ikegami/tmp

$ PWD=/ bash -c pwd     bash's builtin uses $ENV{PWD}
/tmp/ikegami
[download]

The GNU pwd doesn't have any command line options and always gives the path returned by getcwd (with a fallback on error). Darwin's pwd goes a step further and does something that looks awfully familiar.

static char *
getcwd_logical(void)
{
    struct stat lg, phy;
    char *pwd;

    /*
     * Check that $PWD is an absolute logical pathname referring to
     * the current working directory.
     */
    if ((pwd = getenv("PWD")) != NULL && *pwd == '/') {
        if (stat(pwd, &lg) == -1 || stat(".", &phy) == -1)
            return (NULL);
        if (lg.st_dev == phy.st_dev && lg.st_ino == phy.st_ino)
            return (pwd);
    }

    errno = ENOENT;
    return (NULL);
}
[download]

$ ls -l symlink
lrwxrwxrwx 1 david david 22 2011-02-08 10:54 symlink -> foo/bar
$ cd symlink
$ pwd
/home/david/symlink
$ ls -l ..
drwxr-xr-x 2 david david 4096 2011-02-08 10:54 bar
[download]

Note that ls shows us the contents of the parent of the *real* directory that we're in, not the contents of the directory containing the symlink. Symlinks are a bit weird.

$ perl -MFindBin -e 'print "$FindBin::Bin\n"'
/home/david/foo/bar
[download]

FindBin correctly resolves it, giving us the full path to the directory.

FindBin correctly resolves it, giving us the full path to the directory.

As far as I understand, the OP wants the opposite, i.e. the respective symlink path being returned (/home/david/symlink in your case), not the target of the symlink, which is more generally aka realpath, and is easier to determine.

As ikegami pointed out, some other process (usually the shell) needs to keep track of the chdir history to be able to provide the info the OP wants.