On Mon, Jan 17, 2005 at 10:59:54AM -0500, William H. Magill wrote:
[...]
The use of a hash table for command execution/completion was
implemented with csh -- many, many years ago. Those shells which have
descended from csh (tcsh, zsh) behave in this same fashion. It is the
expected behavior.
Sh behavior was always different. It did not use a hash table.
Consequently shells which descended from sh (new sh, bash, ksh) do not
have a hash table.
[...]
bash has a hash table for commands.
The difference is that, when not finding a command in its
hash table, it looks in $PATH for the command (that hash table
doesn't seem to be used for command completion, though ($PATH is
scanned by bash each time you hit tab)).
Note also that I use the term "descended from" quite liberally. In the
beginning there was only Bell Labs and it was called "sh." "sh" was
replaced by "new sh" (frequently called sh5) when it became System V.
Meanwhile BSD created csh to run on top of sh. All Unix variants and
Linux variants boot into some form of "sh." Today, I believe all
variants of Unix and Linux run "new sh" for process 0, which in turn
spawns init. Only after User processes are spawned do the /etc/shells
options come into play.
modern Unices (except Tru64 and Solaris) don't have a SysV shell
anymore. Their /bin/sh is generally a POSIX conformant shell
like ksh, bash or a ash derivative.
I don't think any Unix ever started a shell on boot startup
(except maybe in some specific run-levels).
/etc/shells is a database of valid user shells queried by commands
like chsh, su or in.ftpd (through the GNU or BSD C library function
getusershell for instance), it has nothing to do with the kernel.
"user processes" are spawn from whatever process that changes
the uid (login, su, sudo, dtlogin, xdm...). Typically:
init -> getty -> login (setuid) -> user login shell
or:
init -> startup-script -> su www (setuid) -> httpd
or:
init -> dtlogin startup script -> dtlogin (setuid) -> dtsession
-> dtterm -> user shell
[...]
For some strange reason, throughout the history of Unix, the concept of
"rehash" has always been a deeply guarded secret of the Unix Wizards
... only taught to the truly deserving; neophytes who sought to follow
the ways of the guru. Others were simply told, "Logout and log back in,
and it will work."
In my experience rehash has always been know to csh users.
For the record, the "strange reason" is the difference between the
"System Administrator" (aka root) and the "User" -- everybody else. The
System Administrator is technically the only one who installs (or can
install) software available to anyone other than the person installing
it. "Technically," the System Administrator only does such a thing on a
"closed" system -- i.e. one not permitting user logins (/etc/nologin).
Therefore, the SysAdmin needs to "rehash" for testing purposes, but
everyone else will "automagically" see the new information when they
login.
[...]
Unix environments have often been multiuser environments for
developers. In such contexts, many non-admin users would install
home software on their account and be confronted to the problem.