From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20915 invoked from network); 19 Jan 2005 09:36:46 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Jan 2005 09:36:46 -0000 Received: (qmail 96040 invoked from network); 19 Jan 2005 09:36:37 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Jan 2005 09:36:37 -0000 Received: (qmail 1644 invoked by alias); 19 Jan 2005 09:36:18 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8395 Received: (qmail 1628 invoked from network); 19 Jan 2005 09:36:18 -0000 Received: from unknown (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 19 Jan 2005 09:36:18 -0000 Received: (qmail 94814 invoked from network); 19 Jan 2005 09:35:42 -0000 Received: from 216-19-209-140.getnet.net (HELO mail) (216.19.209.140) by a.mx.sunsite.dk with SMTP; 19 Jan 2005 09:35:37 -0000 Received: from [192.168.1.14] ([::ffff:192.168.1.14]) by mail with esmtp; Wed, 19 Jan 2005 02:50:45 -0700 Message-ID: <41EE29E6.1070502@cql.com> Date: Wed, 19 Jan 2005 02:35:34 -0700 From: Seth Kurtzberg User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Chazelas CC: "William H. Magill" , Bart Schaefer , zsh-users@sunsite.dk, Toshiro Subject: Re: bug (feature?) in zsh References: <200501160216.15097.toshiro@internet.com.uy> <1050116063300.ZM23267@candle.brasslantern.com> <20050118102930.GC4820@sc> In-Reply-To: <20050118102930.GC4820@sc> Content-Type: multipart/alternative; boundary="------------050500080106060601090000" X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=6.0 tests=BAYES_00,HTML_10_20, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.2 X-Spam-Hits: -2.3 This is a multi-part message in MIME format. --------------050500080106060601090000 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Unfortunately, as I believe has been noted, several of the vendors shipping SVR4 UNIX ship with csh as the default shell for the root account. However, they also ship with an equivalent account, toor (root spelled backwards) with either sh or ksh as the shell. Personally, I dropped csh instantly as soon a an alternative with command history (ksh) (let alone completion) became available . There are a few csh features that I like, but, in generally, I find it extremely aggregating to use. I'm not sure why, as I've written code in C almost as soon as it existed, and I still use C in some cases for device drivers, but the shell drives me straight up the wall. On my systems, I create a third user, zoot, which has (surprise) zsh as the shell. I realize the zoot doesn't spell anything backwards, but it seemed like a sensible name to me for some odd reason. Historically, it is true that csh was in no way related (in terms of code reuse) to sh. csh is also, unfortunately, not fully re-entrant, and, for that reason, a good thing to stay away from. In my opinion zsh has every useful csh feature, but that's just my opinion. I've been trying to think of a time recently that I used anything other than !####, and I can't, but I may have forgotten a lot of csh features in the considerable number of years since ksh came out. Since you can run zsh under cygwin, I haven't run any other shell for a long time. I'm something of a zsh zealot, though. Stephane Chazelas wrote: >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. > > > --------------050500080106060601090000 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Unfortunately, as I believe has been noted, several of the vendors shipping SVR4 UNIX ship with csh as the default shell for the root account.=A0 However, they also ship with an equivalent account, toor (root spelled backwards) with either sh or ksh as the shell.

Personally, I dropped csh instantly as soon a an alternative with command history (ksh) (let alone completion) became available .=A0 There are a few csh features that I like, but, in generally, I find it extremely aggregating to use.=A0 I'm not sure why, as I've written code in C almost as soon as it existed, and I still use C in some cases for device drivers, but the shell drives me straight up the wall.

On my systems, I create a third user, zoot, which has (surprise) zsh as the shell.=A0 I realize the zoot doesn't spell anything backwards, but it= seemed like a sensible name to me for some odd reason.

Historically, it is true that csh was in no way related (in terms of code reuse) to sh.=A0 csh is also, unfortunately, not fully re-entrant, and, for that reason, a good thing to stay away from.=A0 In my opinion zsh has every useful csh feature, but that's just my opinion.=A0 I've been trying to think of a time recently that I used anything other than !####, and I can't, but I may have forgotten a lot of csh features in the considerable number of years since ksh came out.

Since you can run zsh under cygwin, I haven't run any other shell for a long time.=A0 I'm something of a zsh zealot, though.

Stephane Chazelas wrote: 
On Mon, Jan 17, 2005 at 10:59:54AM -0500, William H. Mag=
ill wrote:
[...]
  
The use of a hash table for command execution/completi=
on was=20
implemented with csh -- many, many years ago. Those shells which have=20
descended from csh (tcsh, zsh) behave in this same fashion. It is the=20
expected behavior.

Sh behavior was always different. It did not use a hash table.=20
Consequently shells which descended from sh (new sh, bash, ksh) do not=20
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 l=
iberally. In the=20
beginning there was only Bell Labs and it was called "sh." "sh" was=20
replaced by "new sh" (frequently called sh5) when it became System V.=20
Meanwhile BSD created csh to run on top of sh. All Unix variants and=20
Linux variants boot into some form of "sh." Today, I believe all=20
variants of Unix and Linux run "new sh" for process 0, which in turn=20
spawns init. Only after User processes are spawned do the /etc/shells=20
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 Uni=
x, the concept of=20
"rehash" has always been a deeply guarded secret of the Unix Wizards=20
=2E.. 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,=20
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=20
"System Administrator" (aka root) and the "User" -- everybody else. The=20
System Administrator is technically the only one who installs (or can=20
install) software available to anyone other than the person installing=20
it. "Technically," the System Administrator only does such a thing on a=20
"closed" system -- i.e. one not permitting user logins (/etc/nologin).=20
Therefore, the SysAdmin needs to "rehash" for testing purposes, but=20
everyone else will "automagically" see the new information when they=20
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.

--------------050500080106060601090000--