
Tell HN: Bash 'pwd' has different results from /usr/bin/pwd - peterwwillis
<p><pre><code>  $ mkdir tmp1 ; ln -s tmp1 tmp2
  $ ( cd tmp2 ; pwd )
  &#x2F;home&#x2F;user&#x2F;git&#x2F;install&#x2F;src&#x2F;tmp2
  $ ( cd tmp2 ; &#x2F;usr&#x2F;bin&#x2F;pwd )
  &#x2F;home&#x2F;user&#x2F;git&#x2F;install&#x2F;src&#x2F;tmp1
</code></pre>
Apparently bash assumes the &quot;-L&quot; option by default, and coreutils assumes the &quot;-P&quot; option by default. So depending on whether you&#x27;re running pwd from bash or shelling out to &#x2F;usr&#x2F;bin&#x2F;pwd, you may get different results.
======
zimpenfish
> Apparently bash assumes the "-L" option by default > coreutils assumes the
> "-P" option by default

To be fair, these aren't surprising because they're highlighted as such.

`help pwd` says

    
    
        By default, `pwd' behaves as if `-L' were specified.
    

`man pwd` says

    
    
        If no option is specified, -P is assumed.

------
fxfan
Tangential: I'd actually like a protocol that allows a way for external
programs to ask shells to change its directory at their exit.

I wonder if there are ant security concerns to this.

~~~
moviuro
Aliases do that. I'm not sure a function or program can do that.

    
    
      alias mkcd='mkdir -p "$1" && cd "$1"'
      cd "$(something something)"

~~~
jolmg
A function can. Coincidentally, I have a function with the same name and
definition as your example. Actually, after doing a double-take on your alias,
I see it can't work like you probably expect. You can't use arguments like
that. It's simply substitution. If you do:

    
    
      mkcd someplace
    

that'd result in:

    
    
      mkdir -p "$1" && cd "$1" someplace
    

you want:

    
    
      mkcd() { mkdir -p "$1" && cd "$1"; }
    

Anyway, it's subprocesses that can't control the working directory of the
parent process (or other processes for that matter). A process can only
control its own working directory.

~~~
moviuro
yup, my bad! I blame that on not having a shell at work...

