bug in newgrp.c

utzoo!decvax!harpo!seismo!rlgvax!guy utzoo!decvax!harpo!seismo!rlgvax!guy
Fri Feb 25 22:40:10 AEST 1983


I was under the impression that "newgrp" was deliberately passing the "-i"
flag to the new shell; since the "newgrp" command is equivalent to
"exec newgrp", the new shell is still the process group leader (and hence
still the login shell, sort of, although if the C shell keeps a table
internally of the jobs it knows about, they will of course be forgotten
by the new shell unless the old shell passes the info to the new shell
somehow).  You refer to the new shell as a "forked shell", but newgrp
doesn't fork anywhere, and the Algol 68 shell doesn't fork to execute it;
a quick look at the C shell code indicates that it doesn't seem to either.
"Su" DOES fork to execute a new shell, however, so their behavior is not
supposed to be the same.

I figured that "newgrp" was making the new shell a login shell because
"getty" and "login", curse their pointy little heads, won't permit you
to specify a group name as well as a user name when logging in (i.e., you
respond log in like:

login: guy bin

and you will be immediately put in as group "bin" even though your default
group may be "other".).  This way, for example, if your .profile does any
group-dependent processing, it will be performed again (for example, my
.profile sets my umask depending on what group I am in).

					Guy Harris
					RLG Corporation
					...!decvax!mcnc!rlgvax!guy
					...!seismo!rlgvax!guy



More information about the Comp.bugs.4bsd.ucb-fixes mailing list