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]

The portability problem with $ENV{PWD} is that it assumes Unix. `pwd` also assumes Unix. The OP said "though I could replace the Cwd::cwd() calls with `pwd` (for Unix only), I'd prefer a more portable solution."

In addition, $PWD isn't a bashism. csh and ksh also populate it.

The portability problem with $ENV{PWD} is that it assumes Unix. `pwd` also assumes Unix.

You already mentioned that, and I already addressed that. It's still irrelevant and it's still wrong.

It's irrelevant because my solution isn't "use $ENV{PWD}".

It's wrong because the portability of $ENV{PWD} has nothing to do with unix (and even less to do with Unix). It's completely dependent on your shell. It won't work on all unix setups, and it will work on non-unix setups.

In addition, $PWD isn't a bashism. csh and ksh also populate it.

And does Cwd's chdir. Yes, I simplified. The point is that it's shell-specific.