Re: PWD not made canonical on shell start

[Chet Ramey]

On 5/29/17 12:22 PM, dualbus wrote:

> Bash doesn't really do that. What bash does is:

This isn't quite an accurate representation of the bash behavior.

> 
>   case 1)
>   
>   If PWD is passed through the environment,
>   and the value is an absolute pathname of the CWD,
>   then set PWD to the current value from the environment

If PWD appears in the environment, and it is an absolute pathname of the
CWD, set PWD to the canonicalized version of the environment value. The
canonicalized version removes . and .., makes sure that the length is
less than PATH_MAX, and validates that at each step, removing . and ..
results in a valid pathname. If canonicalization fails, PWD gets the value
that would be printed by pwd -P if PWD were not set.

> 
>   case 2)
> 
>   If case 1 does not apply,
>   and the shell is an interactive shell,
>   and the shell is a login shell,
>   and $HOME is the same as the CWD,
>   then set PWD=$HOME

This is to avoid long NFS pathnames from the equivalent of pwd -P when the
current directory is obviously the home directory.

> 
>   case 3)
> 
>   If case 2 does not apply,
>   then call getcwd() and sets PWD to the return value.

That's the behavior of pwd -P when PWD is not set (which it obviously
is not).

> The patch below makes bash behave as described by POSIX.

I'm comfortable with the bash behavior.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/