Why does the cd command handle STDIN different than other commands?

Question

Commands like cd cannot have output piped to them in order to change directories--they require command-line arguments.

Why does the cd command (and those similar to it, such as mv, cp, & rm) not function like most other commands when it comes to reading in STDIN? What's the logic behind preventing it from reading standard input to change directories?

The best answer I could find stated:

cd is not an external command - it is a shell builtin function. It runs in the context of the current shell, and not, as external commands do, in a fork/exec'd context as a separate process.

However, to me the above answer does not really explain it at all: Why does cd handle STDIN different than many other commands who read in STDIN?

Answer 1

The commands that read stdin are almost all of the filter family, i.e. programs that transform a flow of text data to a transformed one.

cat , sed, awk, gzip and even sh are good examples of such "filters".

The cited commands, cp, mv and rm are definitely not filters but commands that do things with the arguments passed, here files or directories.

The cd command is similar to them, it expects an argument (or simulate a default one if not provided), and generally doesn't output anything on stdout, although it might output something on it in some cases like when using CDPATH.

Even if one want to create a cd variant that take the target directory from stdin, it wouldn't have any effect when used in a pipeline in the Bourne shell, dash and bash to name a few. The last component of the command being run in a subshell, the change to a new directory won't affect the current shell. e.g.: echo /tmp | cd would work with ksh93 but not bash, dash, zsh, sh, ...

cd <(echo /tmp) would work with shells supporting process substitution (at least ksh, bash, zsh) but wouldn't have any significant advantage compared to cd $(echo tmp)

The only use case that might be of interest would be something like:

echo tmp | (cd ; pwd)

Finally, such a variant would need to sort out the case it was given no argument but the expected behavior is to change the directory to the users's home or it was given no argument but the expected behavior is to read the name of the target directory from stdin. As there is no reliable way to decide, this is doomed.

Answer 2

Command-line arguments are not at all the same thing as stdin; even commands that use both generally use them for different things. Take cat for example:

echo foo bar | cat    # outputs "foo bar"
cat foo bar           # looks for files named "foo" and "bar", and concatenates them (if found)

If you look at most other commands that read from stdin, you'll find similar things: they don't treat arguments and stdin interchangeably, but as ways of providing different kinds of information to the command.

There are some commands that can take the same type of info either way, but even in those cases there's usually an option you have to specify to tell it which to use. For example, perl reads its program from stdin unless it's told to do otherwise:

echo 'print 1' | perl    # runs "print 1" as a perl program, which prints "1"
perl -e 'print 1'        # runs "print 1" as a perl program, which prints "1"
perl print 1             # tries to run a file named "print" as a script, giving it the argument "1"

...So, I think the premise of the question is false: most commands do not take the same sort of info from stdin that they do from the arguments, so cd is not unusual in this respect.