Vtyjkyuk

I found there are shells like nologin, false, and true. What else are there?

I don't know what is the correct keyword to be used to list the shells. Whenever I search using the keywords linux shell types, I get results in the context of illustrating differences between bash, csh, zsh, and the others.

What is the correct keyword to be used to find more about this subject?

nologin, false, and true, are not shells, they are just ways to prevent login. This leaves the ones ending in sh. So searching in /bin, /usr/bin, etc will help find most that are installed.

Then there is the problem of “what is a shell?” is python, purl, tcl, etc. a shell? Well probably not, but where is the division line? As true, false, and nologin do not interpreters (do not take user input, are not languages, etc), then they are definitely on the not-a-shell side of the line.

However the login shell dose not have to be a shell, it does not even have to be interactive.

You could search on the interweb, using your favorite search engine, for Unix shells.

I found there are shells like nologin, false, and true. What else are there?

These are not shells, as @ctrl-alt-delor already pointed out.

I don't know what to type to list the shells.

You can't get an exhaustive list of all the shells that exist. That would be like asking for a list of all the pieces of software that exist.

Whenever I search with linux shell types (and the likes), I get results in the context of illustrating differences between bash, csh, zsh, and the others you know.

Which is really handy, because these are popular shells you are likely to encounter.

What is the keyword to use to learn more about the subject?

"shell" is also sometimes referred to as a "REPL", "command-line interpreter" or "command language interpreter".

This is a question where the answer is complicated. What most people call a "shell" is a Read-Eval-Print Loop and therefore, even a python interpreter is a shell, provided you are running python interactively. However, this would mean that nologin is not a real shell! So what is a shell?

Technically speaking, any program can be used as a shell. In fact, here are a few pictures of me using unusual shells:

1. Python shell as the login shell


2. 
   Nano as a shell (though you can't distinguish between it being run normally, since it's fullscreen)


3. Cat running as a shell


4. 
   Top running as a shell (even though you, again, can't see it being a shell)


5. And a hello world program!

However, this isn't what you'd expect to be running as shells. Usually, you'll want to be running one of the shells in /etc/shells. For example, mine contains:

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/usr/bin/tmux
/usr/bin/screen

and none of the shells I mentioned previously! So why do they run?

To put it simply, they do, but only locally. If you look at the shells manpage with man shells, you will discover that /etc/shells is mostly used by programs such as FTP daemons. This is why you don't see the nologin shell in /etc/shells: It prevents login to FTP and other non-login daemons by not being there, while preventing login locally by being a simple printf("This account is currently not available"); program, and not a REPL.

So, to answer your question: There is only one type of shell, and that is executable. If you can run a program, it's a shell.

To make the point in the other answers more explicit: There's nothing special about "a shell". This

I understand that nologin, false, and true are actually shells and they are used to prevent users from logging in

is not true: false and true just happened to be programs that were already available on early Unix systems (and they were used in other contexts). What happened is that there was the situation where there were user accounts that didn't correspond to an actual user. So the question was what to put into the "shell" field in /etc/passwd. Because you can put in any program there, the early sysadmins thought it was a cute hack (and practical) to just use /bin/false. Later sysadmins thought it was a bit too much of a hack, and wrote nologin (now that they had more harddisk space to use) to better document this intention.

So: You can use any program as the program that gets spawned when a user logs in. Many programs won't make sense (e.g. when they'd need commandline arguments). Some others will. If you get bored, you can write your own. You don't have to put in any special sauce to make it "a shell".

Anything you want.

A shell is just a TTY application. so anything you can run on a TTY can be a shell.

One example of an unconventional shell would be a bulletin board service:
user logs in via ssh or telnet and gets a BBs instead of a command-line