Required by POSIX, and it does exactly what it's supposed to do: Changes directory in the process (not the parent shell). This isn't completely useless -- you get an exit status and potentially error messages out.
Something to note which wasn't mentioned here is that `cd` is not a binary executable, but instead a shell command. You won't find it anywhere in /bin, /sbin and so on. That's also why `sudo cd ` doesn't work, `sudo` will try to execute `cd` as root but it's not an executable so it won't find it. (tip: do `sudo -i` instead)
cd is a good example of something that has to be a built-in command, because it makes the shell itself do something (change its current working directory). Other commands in that category are umask, the job control ones (fg, bg, wait, ...), the ones setting variables (read, printf), and the control flow ones (if, while, break, return, exit, ...).
A lot of commands are also built-in for convenience but don't strictly need to be.
That sounds like a weird way to implement a built-in command (the IPC handler still needs to be built-in, so you didn't really remove it from the shell). And then if course that binary would be available globally but only work if you're using the shell it's built for...
You could hook up to the parent process with ptrace or the equivalent debugging API of your OS of choice and forcibly change the directory. Stackoverflow even has an implementation: https://unix.stackexchange.com/a/114262/81005
As that comment said, it’s there so utilities can use it for checking the return of “chdir()”. It’s at best a name conflict with a shell command with a well established past and use. At worst, it probably enables some bad code smells or outright malicious code.
We can use the `compgen -b` (`help cd` to get short help or `man bash-builtins` to read man pages) to list all internal bash commands. For example, we can use the `type -a cmd1` or `command -V cmd1` to see if `cmd1` is built-in or external binary.
Don’t forget “dirs -v”. I’ve tried to use Powershell a few times and always tap out because it doesn’t come with the dirs command. It’s so fundamental to my workflow a shell without it or without an easy way to implement it is a no go.
An executable of 'cd' wouldn't do anything useful, it could only change its own idea of working directory then exit, the shell or other executable that invoked it would be unchanged.
Pushd / popd are not POSIX and some shells like ash/dash don't support them. I would avoid them unless you are targeting a specific shell you know supports them (ex: bash).
"targeting" seems like an odd thing to say there. This is an interactive shell command. Does the shell you are using interactively support it seems like a more interesting concern? We don't have to be portable typing commands into a shell. :-)
GP was specifically talking about scripts, and I see the utility.
As an interactive feature, I use the "autopushd" option in zsh, which make all "cd" behave like pushd, and you can also use "cd -n" where "n" is the number of levels you want to go up the stack (so "cd -" is equivalent to "cd -1")
Nice basic introduction. For anyone wanting a comprehensive overview of each command, with examples (and generally more readable than man pages), the computerhope site is good. For example here's wc:
It's UN*X. The one thing it actually does good is having documentation on the system, instead of some weirdo's web page covered in ads. Type man <cmd> or info <cmd> in the shell. Also, for most of the world population, this will be a few seconds faster since it avoids loading a web page.
Probably not popular to say here, but it's ironic that the key benefit of computers is the ability to distance the user from complexity and mind-defeating details, yet computers themselves don't - yet? - offer said type of benefits.
What are you talking about? Of course they do! Try performing any of the operations listed in this article, or making a reply to this comment, by only twiddling the state of the transistors in your CPU.
