From: "William H. Magill" <magill@mcgillsociety.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-users@sunsite.dk, Toshiro <toshiro@internet.com.uy>
Subject: Re: bug (feature?) in zsh
Date: Mon, 17 Jan 2005 10:59:54 -0500 [thread overview]
Message-ID: <D3F8D088-68A0-11D9-8A70-000393768D2C@mcgillsociety.org> (raw)
In-Reply-To: <1050116063300.ZM23267@candle.brasslantern.com>
On 16 Jan, 2005, at 01:33, Bart Schaefer wrote:
> On Jan 16, 2:16am, Toshiro wrote:
> } Subject: bug (feature?) in zsh
> }
> } I'm using Debian unstable, zsh version 4.2.2. I've noticed that,
> when I
> } install a new package that puts some program in my path (for
> } example, /usr/bin) I can't invoke the program using completion in
> any zsh
> } shell that I have opened before installing the program.
>
> This is almost reaching FAQ status, but isn't yet in the FAQ.
>
> The completion system (including compctl) uses the command hash table
> to
> look up names for completion in command position, because it's
> expensive
> to search the path for them. That means that if you install some new
> piece of software, you need to run 'rehash' before the completion
> system
> will see it, as you discovered.
>
> See the zsh-users thread with subject "HASH_LIST_ALL?" from October
> 2004
> for more discussion; in particular, article 8059 presents a technique
> for working around this behavior
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.
This difference was mainly because the "csh" was intended as an
"interactive" shell, and therefore included features (like command
completion) which made usage on what at the time were the standard
input devices -- 110 baud ttys -- much easier on the operator. By
comparison, sh, was deemed a "batch" shell where the full command paths
were expected to be utilized, both as "documentation" in the script and
to assure that the "environment" used by the shell was explicitly what
the script writer wanted, and not that of the entity using the shell.
(Note that this is still considered "Best Practice." And that it is
required for most implementations of "cron" in use today -- the
environment available to the cron job is that of process 1, NOT that of
the User.)
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.
That this is not in the FAQ is not really surprising. Interesting, but
not surprising.
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."
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.
Today, there are probably far more "SysAdmins" supporting "single-user"
boxes, especially under Linux, than there are SysAdmins supporting
multi-user, time-sharing systems. This is especially true with the
widespread use of sudo as opposed to actually logging in as the root
user.
T.T.F.N.
William H. Magill
# Beige G3 [Rev A motherboard - 300 MHz 768 Meg] OS X 10.2.8
# Flat-panel iMac (2.1) [800MHz - Super Drive - 768 Meg] OS X 10.3.7
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg] Tru64 5.1a
# XP1000 [Alpha 21264-3 (EV6) - 256 meg] FreeBSD 5.3
# XP1000 [Alpha 21264-A (EV 6.7) - 384 meg] FreeBSD 5.3
magill@mcgillsociety.org
magill@acm.org
magill@mac.com
whmagill@gmail.com
next prev parent reply other threads:[~2005-01-18 3:07 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 [this message]
2005-01-17 23:11 ` Bart Schaefer
2005-01-18 10:29 ` Stephane Chazelas
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=D3F8D088-68A0-11D9-8A70-000393768D2C@mcgillsociety.org \
--to=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).