From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by hawkwind.utcs.toronto.edu with SMTP id <2689>; Fri, 4 Dec 1992 10:00:59 -0500
Received:  by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins)
	id AA04385; Fri, 4 Dec 92 09:58:58 -0500 (from chet for rc@hawkwind.utcs.toronto.edu)
Date:	Fri, 4 Dec 1992 09:52:42 -0500
From:	Chet Ramey <chet@odin.INS.CWRU.Edu>
To:	culliton@srg.af.mil
Subject: Re: More stuff related to exec...
Cc:	rc@hawkwind.utcs.toronto.edu, chet@odin.INS.CWRU.Edu
Reply-To: chet@po.CWRU.Edu
In-Reply-To: Message from culliton@srg.af.mil of Thu, 3 Dec 1992 11:37:31 -0500
Message-Id: <9212041452.AA04276.SM@odin.INS.CWRU.Edu>
Read-Receipt-To: chet@po.CWRU.Edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> Here, presented for your amusement, is a cute little stunt that sh,
> ksh, and csh do and that rc, and bash do not.
> 
> If you have occasion to use the "newgrp" command or read the man page
> it says that when you run newgrp it replaces the current shell
> (effectively an exec) this obviously entails magic within the shells
> (try "strings /bin/sh | grep newgrp")  Not only that, but newgrp seems
> to revert to the shell named in the login file, ignoring the current
> setting of SHELL.

With the advent of BSD-like multiple groups in Posix and most Unix versions,
it's not worth the space it takes to have a `newgrp' shell builtin.

> If you care about the exec behaviour you can obviously create a newgrp
> function ("fn newgrp { exec /bin/newgrp $* }").  As for the other, it
> looks like that's just the way the ball bounces.  Isn't unix fun? ;-)

Shells that have a newgrp builtin just do the exec internally, so a shell
function suffices.  (Look at the tcsh source, for instance.)  That is, if
you care enough about newgrp to want one.

Chet

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu