[ILUG] cvs

[Brian Foster]

  | Date: Tue, 18 Jun 2002 16:00:17 +0100
  | From: "John P. Looney" <john at 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 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...