Tell HN: Bash 'pwd' has different results from /usr/bin/pwd | Hacker News Reader

Tell HN: Bash 'pwd' has different results from /usr/bin/pwd

4 pointspeterwwillis5 comments

  $ mkdir tmp1 ; ln -s tmp1 tmp2
  $ ( cd tmp2 ; pwd )
  /home/user/git/install/src/tmp2
  $ ( cd tmp2 ; /usr/bin/pwd )
  /home/user/git/install/src/tmp1

Apparently bash assumes the "-L" option by default, and coreutils assumes the "-P" option by default. So depending on whether you're running pwd from bash or shelling out to /usr/bin/pwd, you may get different results.

View on HN

> 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.

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.

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

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

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.

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

Reply on news.ycombinator.com