Zsh Mailing List Archive
Messages sorted by:
Re: bug (feature?) in zsh
- X-seq: zsh-users 8393
- From: Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>
- To: "William H. Magill" <magill@xxxxxxxxxxxxxxxxx>
- Subject: Re: bug (feature?) in zsh
- Date: Tue, 18 Jan 2005 10:29:30 +0000
- Cc: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxx, Toshiro <toshiro@xxxxxxxxxxxxxxx>
- In-reply-to: <D3F8D088-68A0-11D9-8A70-000393768D2C@xxxxxxxxxxxxxxxxx>
- Mail-followup-to: "William H. Magill" <magill@xxxxxxxxxxxxxxxxx>, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxx, Toshiro <toshiro@xxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <200501160216.15097.toshiro@xxxxxxxxxxxxxxx> <1050116063300.ZM23267@xxxxxxxxxxxxxxxxxxxxxxx> <D3F8D088-68A0-11D9-8A70-000393768D2C@xxxxxxxxxxxxxxxxx>
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
init -> startup-script -> su www (setuid) -> httpd
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
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.
Messages sorted by: