From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17426 invoked from network); 18 Jan 2005 10:28:20 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Jan 2005 10:28:20 -0000 Received: (qmail 22458 invoked from network); 18 Jan 2005 10:28:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Jan 2005 10:28:14 -0000 Received: (qmail 19120 invoked by alias); 18 Jan 2005 10:28:07 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8393 Received: (qmail 19105 invoked from network); 18 Jan 2005 10:28:07 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Jan 2005 10:28:07 -0000 Received: (qmail 21451 invoked from network); 18 Jan 2005 10:28:07 -0000 Received: from smtp-out3.blueyonder.co.uk (195.188.213.6) by a.mx.sunsite.dk with SMTP; 18 Jan 2005 10:28:03 -0000 Received: from sc ([82.41.215.7]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jan 2005 10:28:35 +0000 Date: Tue, 18 Jan 2005 10:29:30 +0000 From: Stephane Chazelas To: "William H. Magill" Cc: Bart Schaefer , zsh-users@sunsite.dk, Toshiro Subject: Re: bug (feature?) in zsh Message-ID: <20050118102930.GC4820@sc> Mail-Followup-To: "William H. Magill" , Bart Schaefer , zsh-users@sunsite.dk, Toshiro References: <200501160216.15097.toshiro@internet.com.uy> <1050116063300.ZM23267@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.6i X-OriginalArrivalTime: 18 Jan 2005 10:28:35.0959 (UTC) FILETIME=[779EE070:01C4FD48] X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 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