From: Brian Foster (blf at domain utvinternet.ie)
Date: Wed 19 Jun 2002 - 05:16:51 IST
| Date: Tue, 18 Jun 2002 16:00:17 +0100
| From: "John P. Looney" <john at domain antefacto.com>
|
| On Tue, Jun 18, 2002 at 03:54:42PM +0100, Kenn Humborg mentioned:
| > > Does this user have access to write to the /home/cvsroot/CVSROOT
| > > directory?
| > > Remember you need to relogin (or go hash -r in bash) to recognise
| > > that you've
| > > just been added to the group.
| > [ `hash -r' ] sounds very, very wrong. Are you sure about this?
| > Can you provide a reference?
|
| I'm so sure that hash -r rereads in binarys that the filename completeion
| had cached.
NO. from the bash(1) man page:
Bash uses a hash table to remember the full pathnames of
executable files [ ... ]. A full search of the directories
in PATH is performed only if the command is not found in
the hash table. [ ... ] The -r option causes the shell
to forget all remembered locations.
the shell, in normal operation, never "reads in binaries";
_why_ would it ??? the only files a shell normally reads
are scripts (including your terminak), which it executes
(interprets). binaries, more accurately executable binaries,
are loaded into memory by the kernel (on *ix systems, modern
O/Ses do it sensibly), and self-execute. the shell's primary
role w.r.t. binaries is to create a new process with fork(2),
which then initiates the load-then-self-execution with exec(2).
file-name-completion may add to the hash table, and/or lookup
possible names in the hash table, but is mostly orthogonal.
| The group thing - you need to switch groups with "sg" sometimes, no ?
yes and no. if you've added yourself to a group, none of your
current processes will (obviously) have that new-to-you group
as part of their grouplist (secondary groups). hence, it will
appear that the new group has "no effect". (this may be the
problem, or at least part of it, the original poster has.)
creating (i.e., `fork'ing) a new process from such an existing
process doesn't help; a child inherits the groups of the parent.
to have the new group "take effect", you must either logout
and log back in again; or, use a command such as sg(1) or
newgrp(1) to create a new process (typically a shell) with
the specified group. AFAIK, both `newgrp' and GNU `sg' can
only change the both the RGID and EGID, and never change
the grouplist; hence, they quite often (IMHO) don't really
do what's presumed/intended/wanted. yer probably better off
logging in again --- or using su(1), or, if allowed on your
system, command-line login(1).
the CVS instructions make a point of saying you have to log
in again, and show using `su' (check the original post).
nonetheless, AFAIK people tend to skip that step 'cuz they
"already are logged in". and then it doesn't work, just
as described ..... (whether or not this is actually what
went wrong in this case I've no idea.)
cheers!
-blf-
p.s. as an aside, for a commercial *ix vendor I spec'ed a
command --- then implemented by someone else --- also
called "sg" (it predated GNU), which could change the
EGID and(/or?) RGID, and/or modify the grouplist,
before running the specified command .....
--
Innovative, very experienced, Unix and | Brian Foster Dublin, Ireland
Chorus (embedded RTOS) kernel internals | e-mail: blf at domain utvinternet.ie
expert looking for a new position ... | mobile: (+353 or 0)86 854 9268
For a résumé, contact me, or see my website http://www.blf.utvinternet.ie
Stop E$$o (ExxonMobile): «Whatever you do, don't buy Esso --- they
don't give a damn about global warming.» http://www.stopesso.com
Supported by Greenpeace, Friends of the Earth, and numerous others...
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:17:20 GMT