From: Stephane Chazelas <Stephane_Chazelas@yahoo.fr>
To: "William H. Magill" <magill@mcgillsociety.org>
Cc: Bart Schaefer <schaefer@brasslantern.com>,
zsh-users@sunsite.dk, Toshiro <toshiro@internet.com.uy>
Subject: Re: bug (feature?) in zsh
Date: Tue, 18 Jan 2005 10:29:30 +0000 [thread overview]
Message-ID: <20050118102930.GC4820@sc> (raw)
In-Reply-To: <D3F8D088-68A0-11D9-8A70-000393768D2C@mcgillsociety.org>
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
next prev parent reply other threads:[~2005-01-18 10:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-16 4:16 Toshiro
2005-01-16 6:33 ` Bart Schaefer
[not found] ` <1105860898.14494.0.camel@amethyst.cql.com>
2005-01-16 19:30 ` Toshiro
2005-01-17 15:59 ` William H. Magill
2005-01-17 23:11 ` Bart Schaefer
2005-01-18 10:29 ` Stephane Chazelas [this message]
2005-01-19 9:35 ` Seth Kurtzberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050118102930.GC4820@sc \
--to=stephane_chazelas@yahoo.fr \
--cc=magill@mcgillsociety.org \
--cc=schaefer@brasslantern.com \
--cc=toshiro@internet.com.uy \
--cc=zsh-users@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).