Why a change of dir can't be made in a separate process?

Question

Why we can't create a process which change the current working dir. Just like cd command does?

Answer 1

Think about what you're asking. You have a shell, and you want to write an external program that will change the shell's cwd. Does that even make sense? To me it sounds like you're not quite groking the way a shell is just a program that accepts a string and spawns some subprocesses (which naturally inherit the cwd of their parent, the shell).

I suspect you could do it hackishly, perhaps by using ptrace to inject commands into the shell process. You could write your own shell that kept a distinct setting for "child wd" (the main change is that after it forks a child, it would need to remember to chdir()). You could write a kernel module that would let you forcibly change an arbitrary process's cwd, though I expect that would break things more than it would be useful.

If this kind of thing made any sense, you could (with appropriate permissions), do "ln -fs /somewhere /proc/$pid/cwd". When I try that as root, I get "ln: cwd/: cannot overwrite directory" - from strace, it looks like it's checking and noticing that the target already exists. symlink() appears to fail in that case, so the symlink command, would presumably have to remove the existing link first, and I don't think the kernel would let that happen.

Answer 2

Processes are the main unit of doing anything on the computer. They encapsulate things like virtual memory and its contents, the state of CPU registers and the instruction pointer (pointer to where the code is running), and on the OS level, things like open files and the working directory. These are things a running process needs to be unchanged by external events for the program logic to work.

If the CPU registers or the instruction pointer changed when the program was running, very unexpected things would happen. Similarly, changing open files from under the program might e.g. cause an HTTP server to suddenly switch to serving the wrong file, or to read from a wrong configuration file without even knowing about it. And changing the working directory of a process would cause it to find the wrong files if it used relative paths. Or remove them; think what happened if a running rm -rf somedir was suddenly moved to another directory: it would start removing files from the wrong place.

Hence, it's a not a good idea to allow doing that without the cooperation of the process itself. You could of course create a program that changes its own working directory, but having another program do that for the shell would not be a very good idea. Also it's not necessary, since the shell can well do it itself with a builtin command, and if you need to customize it, you can do it with a shell function. Possibly using an external program to choose the directory to change to, while still having the shell's own cd to do the actual change. E.g. think something like cdfoo() { cd -- "$(get_foo_dir "$1")"; }.

Answer 3

You cannot change the current working directory in a child process because ... you can actually do it just fine.

The clone(2) Linux system call which is used to create a process (and implement legacy interfaces like fork(2)) has a CLONE_FS flag which can be used to let the child share the root directory, current working directory and umask with its parent:

#define _GNU_SOURCE
#include <sched.h>
#include <unistd.h>
#include <syscall.h>
#include <sys/wait.h>
#include <err.h>
int main(void){
        pid_t cpid = syscall(SYS_clone, CLONE_FS, (void)0);
        if(cpid == -1) err(1, "SYS_clone");
        if(cpid == 0){
                / the child, change the cwd and exit /
                execl("/bin/sh", "sh", "-c", "cd /etc", (void)0);
                err(1, "execl /bin/sh");
        }else{
                /* the parent, wait for the child, then print the cwd /
                waitpid(-1, 0, __WALL);
                execl("/bin/sh", "sh", "-c", "pwd", (void)0);
                err(1, "execl /bin/sh");
        }
}

That does not work in the shell because the bourne shell (of which bash is an implementation) doesn't use that flag when forking separate processes and running external commands; but the shell is a antiquated piece of work which has a LOT of absurd limitations (it also doesn't have lexical scoping, direct access to the system's interfaces, a sane and regular syntax, and many many other things).

You should not extrapolate the ineptness of a 45 years old toy-language to the entire system, which has seen a lot of evolution.

---

Far from being something something natural and obvious, the fact that cd "could not" be an external command (and the very necessity of a current directory!) has more to do with the stepwise evolution of Unix and the constraints of the PDP-7 system on which it first ran.

From "Dennis Ritchie -- The Evolution of the Unix Time-Sharing System":

In spite of its considerable similarity to the current file system, the PDP-7 file system was in one way remarkably different: there were no path names, and each file-name argument to the system was a simple name (without ‘/’) taken relative to the current directory.

...

Although the multiple-process idea slipped in very easily indeed, there were some aftereffects that weren’t anticipated. The most memorable of these became evident soon after the new system came up and apparently worked. In the midst of our jubilation, it was discovered that the chdir (change current directory) command had stopped working. There was much reading of code and anxious introspection about how the addition of fork could have broken the chdir call. Finally the truth dawned: in the old system chdir was an ordinary command; it adjusted the current directory of the (unique) process attached to the terminal. Under the new system, the chdir command correctly changed the current directory of the process created to execute it, but this process promptly terminated and had no effect whatsoever on its parent shell!

---

From comments:

No sane shell (a program executing arbitrary externally-supplied commands) can afford to use CLONE_FS, as then all its child processes would fight over the control of the current directory

That's a fallacy. It's like "we cannot allow plumbers because there would be no more bus drivers". The shell could obviously do that only in some cases. The children already "fight" over the standard file descriptors (making the stdin non-blocking in the child also makes it non-blocking in the parent), over the current namespace (mounting a directory in the child also mounts it in the parent), and all the various pieces which could be shared or split via CLONE_* or other system interfaces. The "working directory" is just a piece of the execution environment, and rather a compatibility than an essential one (on every modern system it's possible to open relative paths wrt another directory -- see all the openat(2), linkat(2), etc functions).

It's not some law of nature that a child process should not be able to change the working directory of its parent, but it should be perfectly able to move or remove it (as it already is). The default of 50 years ago is not some golden standard -- for instance, I would rather have a shell where the default would be to run an awk or jq filter command in way in which it could change the shell's working directory, rather than in a way in which it could wipe off my files (which is the case now).