The ability to specify a shell in /etc/passwd is extremely long-standing: it is documented in the passwd(5) manpage of 1st Edition UNIX dated 1971 (https://www.

The ability to specify a shell in /etc/passwd is extremely long-standing: it is documented in the passwd(5) manpage of 1st Edition UNIX dated 1971 (https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passwd.5 https://www.tuhs.org/cgi-bin/utree.pl?file=V1/man/man5/passw...). My guess is that in 1971 you really didn't want to spawn a shell process unnecessarily on a multi-user pdp-11 (not because you're charged for it but because the machine is small and you don't want to waste ram or cpu). It also means you can say "use my locally compiled bugfixed shell binary that reads the same startup/init files as the standard system one", and you can have 'system' users with non-standard special-purpose shells -- 7th Ed's /etc/passwd (https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd https://www.tuhs.org/cgi-bin/utree.pl?file=V7/etc/passwd) has a uucp user whose shell is the uucico program, so a remote system can dial in, log in as 'uucp' and trigger file transfer. These days we'd probably also think about reducing 'attack surface' by not giving that kind of special purpose user a real shell even in passing (if a bug let them write to the shell's init files that turns write-file-as-user into remote-shell), but they wouldn't have been considering that in the early 70s...