exporting CDPATH to subshell could be harmful on macOS

[anpol]

To reproduce, execute the following script on macOS:

#!/usr/bin/env bash

mkdir test; cd test
mkdir foo bar 2>/dev/null

cat <<END >.envrc
export CDPATH=foo:bar:baz
END

direnv allow .

eval "$(direnv export bash)"

# The following /bin/sh script could fail.
/bin/sh <<END
echo bash "$BASH_VERSION"
cd foo
cd ../bar
END

This script fails with the following output:

direnv: loading .envrc
direnv: export +CDPATH
bash 3.2.57(1)-release
/bin/sh: line 2: cd: foo: No such file or directory
/bin/sh: line 3: cd: ../bar: No such file or directory

On macOS, /bin/sh is the bash version 3.2, incorrectly handling CDPATH environment variable, as described here: http://unix.stackexchange.com/a/112364 – cd command just fails as above.

The solution could be to prevent exporting CDPATH to subshells, as it's not of much use of it out of interactive shell.

But with direnv it's not possible to define a variable without exporting it.

I suggest handling CDPATH in a special way, allowing it to be exported from .envrc, but preventing it to be further exported to subshells. What I mean is that $(direnv export) should output just CDPATH=... without the export qualifier.

[anpol]

More details on exporting CDPATH: https://bosker.wordpress.com/2012/02/12/bash-scripters-beware-of-the-cdpath/

[zimbatm]

Interesting. I have another variable that would best be set instead of exported: PS1.

Direnv doesn't really have a mechanism for that. If I get around to rewrite direnv I will take that into account.