[abhishekjha]

>SO!! If you had a /usr/bin/cd program that ran chdir, that would be fine, but when you started it it would change its own working directory and exit which is not very helpful. It wouldn’t change the working directory of you (the parent process)

I am a little confused. What is the parent process and why does that matter here?

[Someone1234]

The parent is the shell that called the theoretical /user/bin/cd. It means that a cd program would get launched by the shell, change its own working directory and then terminate, which is completely useless.

What you want cd to do is change the caller's (or parent's) working directory, or in this case the shell's working directory.

There are hacks to do it that you can find elsewhere in this thread (process injection and debug APIs to name two) but frankly the shell changing its own working directory via a builtin is a much simpler and more reliable solution that is also cross-platform.

[abhishekjha]

Ah. This makes sense. Thanks. I will look into the hacks.

[matheusmoreira]

When a process X creates another process Y, what happens is X becomes the parent of Y and Y becomes a child of X. All processes are created this way. They form a tree structure with PID 1 as the root. The very first process is spawned by Linux itself. Processes are isolated by default and thus cannot modify each other's state.

If we have a shell and we use it to start up a separate chdir program, we get two processes: shell (parent) and chdir (child). The kernel isolates them from each other, so they both have completely distinct working directories. The chdir executes the relevant system call, changes its own working directory and exits. The shell is not affected by the system calls performed by its children, so the chdir process effectively does nothing.

By implementing chdir as a built-in function, the shell is able to change the state of its own process.