Can I make cd be local to a function?

Question

Is it possible to make a function like

function doStuffAt {
    cd $1
    # do stuff
}

but make it so invoking that function doesn't actually change my pwd, it just changes it for duration of the function? I know I can save the pwd and set it back at the end, but I'm hoping there's a way to just make it happen locally and not have to worry about that.

Answer 1

Yes. Just make the function run its commands in a ( ) subshell instead of a { } group command:

doStuffAt() (
        cd -- "$1" || exit # the subshell if cd failed.
        # do stuff
)

The parentheses (( )) open a new subshell that will inherit the environment of its parent. The subshell will exit as soon as the commands running it it are done, returning you to the parent shell and the cd will only affect the subshell, therefore your PWD will remain unchanged.

Note that the subshell will also copy all shell variables, so you cannot pass information back from the subshell function to the main script via global variables.

For more on subshells, have a look at man bash:

(list)

list is executed in a subshell environment (see COMMAND EXECUTION ENVIRONMENT below). Variable assignments and builtin commands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list.

Compare to:

{ list; }

list is simply executed in the current shell environment. list must be terminated with a newline or semicolon. This is known as a group command. The return status is the exit status of list. Note that unlike the metacharacters ( and ), { and } are reserved words and must occur where a reserved word is permitted to be recognized. Since they do not cause a word break, they must be separated from list by whitespace or another shell metacharacter.

Answer 2

It depends.

You can put the function in a subshell. (See also Do parentheses really put the command in a subshell?) What happens in a subshell stays in a subshell. Changes that the function makes to variables, the current directory, to redirections, to traps, and so on, do not affect the calling code. The subshell inherits all these properties from its parent but there is no transfer in the other direction. exit in a subshell only exits the subshell, not the calling process. You can put a piece of code in a subshell by wrapping it in parentheses (line breaks and even whitespace before and after the parentheses are optional):

(
  set -e # to exit the subshell as soon as an error happens
  cd -- "$1"
  do stuff # in $1
)
do more stuff # in whatever directory was current before the '('

If you want to run the whole function in a subshell, you can use parentheses instead of braces to wrap the function's code.

doStuffAt () (
    set -e
    cd -- "$1"
    # do stuff
)

With the Korn-style function definition syntax, you need:

function doStuffAt { (
    set -e
    cd -- "$1"
    # do stuff
) }

The downside of a subshell is that nothing escapes it. If you need to change the current directory but then update some variables, you can't do that with a subshell. There are only two easy ways to retrieve information from a subshell. Like any other command, a subshell has an exit status, but this is an integer between 0 and 255 so it doesn't convey much information. You can use a command substitution to produce some output: a command substitution is a subshell whose standard output (minus trailing newlines) is collected into a string. This lets you output one string.

data=$(
  set -e
  cd -- "$1"
  do stuff # in $1
)
# Now you're still in the original directory, and you have some data in $data

You can save the current directory into a variable, and restore it later.

set -e
old_cwd="$PWD"
cd -- "$1"
…
cd "$old_cwd"

However this is not very reliable. If the code exits between the two cd commands, it'll be in the wrong directory. If the old directory is moved in the meantime, the second cd will not return to the right place. It's possible to be in a directory that you have no permission to change into (because the script has less privileges than its caller), and in this case the second cd will fail. So you should not do this unless you're in a controlled environment where this can't happen (for example, to cd into and out of a temporary directory created by your script).

If you need to both change directory temporarily and affect the shell environment in some way (such as setting variables), you need to carefully split your scripts into parts that affect the shell environment and parts that change the current directory. The shell inherits limitations of early unix systems which didn't have a way to return to the previous directory. Modern unix systems do (you can “save” the current directory's file descriptor, and return to it with fchdir() in an exception handler), but there's no shell interface to this functionality.

Answer 3

When descending into a directory "temporarily" to do some work — IOW, when you want to scope the directory change in some way — it makes sense to take advantage of the directory stack by using pushd and popd. It's a common technique in things like build scripts.

Say you're building a bunch of plugins.

for plugindir in plugin1 plugin2 plugin2 plugin4; do
  pushd -- "$plugindir"
  make
  popd
done

Answer 4

[this answer is assuming bash; it won't work with other shells]

Using a subshell is simple and perfectly fine in most practical cases, except when your function has to modify variables in the main script.

For that case, you can use a RETURN trap to change back to the old current directory upon returning from the function. The RETURN trap is invoked no matter how your function is exited, and is not inherited by default by other functions.

doStuffAt(){
    cd -- "$1" || return
    local opwd=$OLDPWD
    trap 'cd "$opwd"' RETURN
    #
    # do stuff
    shift; "$@"
    # change some variable
    wasAt+=("$PWD")
}
% doStuffAt /
% pwd
/home/user
% doStuffAt /usr
% echo ${wasAt[@]}
/ /usr

But the old directory could've been renamed when you try to change back to it, and you will not be able to do it via its path. On Linux, you can emulate with /dev/fd in the shell the safer method of opening a file descriptor to . and then calling fchdir on it:

doStuffAt() {
    local fd
    command exec {fd}< . || return
    trap 'cd -P "/dev/fd/$fd"; exec {fd}<&-' RETURN; exec {fd}<.
    cd -- "$1" || return
# do stuff
shift; &quot;$@&quot;
# change some variable
wasAt+=(&quot;$PWD&quot;)

}

Here {fd}<. is used with a local variable instead of a fixed fd so that function be re-entrant.

Notice that cd -P /dev/fd/X will succeed even if the leading directories from its resolved path are not accessible. Simple example:

t=$(mktemp -d); mkdir -p $t/b/c; exec 7<$t/b/c; chmod -rwx $t
cd -P /dev/fd/7  # this will succeed
pwd
cd $(pwd)        # this will fail

Of course, the old cwd could be made itself inaccessible, instead of the dirs leading to it (by removing its x mode); but in that case, fchdir(2) wouldn't have helped either.

Also, there's still the case where the old cwd was removed. For that case, the trap could be changed to cd "/dev/fd/$fd"; cd -P . 2>/dev/null (the -P being mostly for cosmetical purposes). But it's not clear how changing back to an empty deleted directory would be useful at all.

Answer 5

Invoke it in a subshell.

(doStuffAt some/path/)