Re: bug (feature?) in zsh

[Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>]

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.

-- 
Stéphane