- Does a system call function often but not always have a command or utility in shell?
Sometimes. System calls that are useful to expose, are usually exposed. A shell that couldn't change directories would not be a very useful shell. Some of them, like
chdir, are implemented as shell builtins, because they can only affect the process that called them. Others are implemented as small programs. Still others are not exposed at all: there is very little reason to ever call
mmap directly from the shell, so you can't, unless you write a wrapper yourself (which would be useless anyway).
- Is there some rule of thumb about what kinds of system calls have corresponding commands or utilities in shell, and what kinds of commands or utilities in shell have corresponding system calls?
There is no standard correspondence or rule of thumb. The names may be anything, for example
rm is implemented in terms of the
unlink syscall; however there is also an
unlink command that also does this, but lacks most command line options and is basically just a wrapper. And the
pipe syscall, along with the corresponding
writes, are exposed through the
man syscalls ought to give you a list of system calls.
- For a system call and a corresponding shell command or utility, is the command or utility always implemented in the same way as the system call? Is the implementation even based on the system call?
The utilities just use the system calls, in fact, this is the only way that the utilities could do these things. You couldn't, say, delete a file or change permissions without going through the syscall mechanism, whether directly or indirectly.
(Imagine what it would be like if this were not the case. Every program that wanted to delete a file would have to implement its own filesystem drivers and hard disk drivers. There would also be no security, because every program would be responsible for checking its own permissions. Instead, you just use a syscall and then the kernel figures everything out.)