bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PWD not made canonical on shell start


From: Chet Ramey
Subject: Re: PWD not made canonical on shell start
Date: Mon, 29 May 2017 18:25:06 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

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    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]