whb@vax135.UUCP (Wilson H. Bent) (01/31/86)
This may have been discussed before, but... (Don't you just hate these ignorant openers?) What happened to "newgrp" in 4.2BSD? I can't get either Bourne Shell or C Shell to admit anything, and it's not in the manual. Just to add to the irritation, it's mentioned (VERY briefly) in the Korn Shell manual, but I still get "ksh: newgrp not found"!!! Our use of it is to re-read .profile or .login or whatever, to re-initialize some shell/environment variables. I didn't come up with this method, nor did anyone I can point to, so don't flame me. My solution is (in this case) to just put the line ". .profile" in the appropriate place, instead of "newgrp". Is there a reason why this won't work? And why was newgrp dropped? -- Wilson H. Bent, Jr. ... ihnp4!vax135!hoh-2!whb AT&T - Bell Laboratories (201) 949-1277 Disclaimer: My company has not authorized me to issue a disclaimer.
jsdy@hadron.UUCP (02/05/86)
Newgrp's function was to be exec'd by the shell without forking,
change the process group-id, and then exec another shell. Depending
on which version of which Unix you got, I don't think there was any
guarantee it would read your .profile. (Opinions differed -- this
is why csh has .cshrc and .login, and ksh has ${ENV} and .profile.)
The two things that process group-id's were used for were to control
access relative to files' group permissions, and to determine what
group would be associated with files that were written.
Under 4.2 BSD, processes still have group-id's, the way humans still
have appendices. They aren't used for anything I can see. File access
is determined by your group vector, rather than your group ID. (Rather
a neat idea, but can cause problems, such as ...) So which group ID
goes with a created file? None: it inherits it from the directory
in which it finds itself.
Thus, Berkelians figured that 'newgrp' no longer needed to exist.
However, right again, this breaks existing code that calls newgrp.
-flame- .sputter.
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}romain@pyrnj.uucp (Romain Kang) (02/06/86)
In article <235@hadron.UUCP>, jsdy@hadron.UUCP (Joseph S. D. Yao) writes: > Under 4.2 BSD, processes still have group-id's, the way humans still > have appendices. They aren't used for anything I can see. File access > is determined by your group vector, rather than your group ID. (Rather > a neat idea, but can cause problems, such as ...) So which group ID > goes with a created file? None: it inherits it from the directory > in which it finds itself. > > Thus, Berkelians figured that 'newgrp' no longer needed to exist. > However, right again, this breaks existing code that calls newgrp. > -flame- .sputter. And of course, if you decide you *have* to be a member of more than eight groups simultaneously, you have to recompile the entire kernel. Also, system performance tends to suffer slightly because the permission checking mechanism does a linear probe of your group vector (in the user structure). Since the user structure gets changed, all sorts of other things in Unix have to be recompiled, too. At a site where I once consulted, we changed NGROUPS from 8 to 20. We had to rebuild the following stuff: /usr/src/lib/libc/gen/initgroups.c replace function in /lib/libc.a, /usr/lib/libc_p.a initgroups() dependents: /usr/src/bin/{login.c,su.c} /usr/src/ucb/groups.c probably others... /usr/src/bin/{ps.c,adb/*} /usr/src/ucb/{{w,gcore}.c,dbx/*} /usr/src/etc/{pstat,analyze}.c I probably missed other things. In retrospect, it probably would have been quicker to re-implement the newgrp command (even if the shell didn't fork it directly.) -- Romain Kang, Pyramid Technology Corporation US Mail: 900 Route 9, Woodbridge, NJ 07095 Ma Bell: (201) 750-2626 UUCPnet: {allegra,cmcl2,pyramid,topaz}!pyrnj!romain "Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson